[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