[FFmpeg-cvslog] r8916 - in trunk/libavcodec: vc1.c vc1data.c vc1data.h

Rich Felker dalias
Mon May 7 17:10:48 CEST 2007


On Sun, May 06, 2007 at 10:38:52PM +0200, matthieu castet wrote:
> >> As for better modularity more and more static variables become global. 
> >> Couldn't we introduce a __attribute__visibility_hiden for the compilers 
> >> that support it ?
> > 
> > No, all this does is allow bugs to slip through that result in broken
> > builds on other platforms. Using nonportable hacks is not the way to
> > fix namespace issues. It's like removing -Wall when you get a warning
> > about code that's nonportable rather than fixing the code...
> > 
> What's the problem ?
> For the other platforms it is the same than before :

No, it's much worse, because the bugs don't get caught by the 90%
majority (and nearly all developers) who use GNU/Linux, then they
mysteriously affect the 10% minority later. It's much better if the
bugs show up right away and people have to fix them!

>  > Of course the variable should still prefixed
> 
> Another solution, I saw in some libraries was to prefix the internal 
> symbols with a random pattern that can be chosen by a define. It is 
> portable, but for each internal declaration, you should do something 
> like : `int INTERNAL_SYMBOL(foo);' which a bit ugly.

Actually it's not ugly if you hide them all away in an internal header
with things like

#define symbol1 INTERNAL_SYMBOL(symbol1)
#define symbol2 INTERNAL_SYMBOL(symbol2)
#define symbol3 INTERNAL_SYMBOL(symbol3)
....

Then all the actual code still looks clean. But I don't see this
really being any better than just using the ff_ prefix... and it
involves a degree of obfuscation which is always bad.

Rich




More information about the ffmpeg-cvslog mailing list