[Zlib-devel] Re: ABI compatibility of zlib 1.0.x, 1.1.x, and 1.2.x

[Jeff Johnson]

Cosmin Truta wrote:

>On Fri, 5 Dec 2003, Jeff Johnson wrote:
>
>  
>
>>Cosmin Truta wrote:
>>
>>    
>>
>>>Although it's superfluous, something has to be stated about NOT relying
>>>at all on private symbols that leak out of "zlib.h", or on pieces of
>>>code that do more than the documentation claims.
>>>
>>>      
>>>
>>There is attribute magic to deal with "symbols that leak" if using
>>gcc/binutils that
>>should not hurt non-gcc platforms.
>>    
>>
>
>The exports that aren't visible from "zlib.h" (like _tr_tally and such),
>aren't that much a problem. If the attribute magic will add a big bunch
>of #ifdefs, then I'd prefer to keep the headers/source clean and write a
>simple "don't use" statement in the docs instead.
>  
>

Not #ifdef's, additional
     attribute(""hidden")
markers that permit linking for a library, but do not expose the symbols 
with -lzlib is used.

>The problem is with macros like ZLIB_H, ZEXPORT, SYS16BIT, etc. that
>aren't supposed to be relied on by users, but they leak out of "zlib.h".
>  
>

Hmmm, #define constants is not exactly symbol leakage, but problem 
understood.

>  
>
>>I can take a shot at a patch to eliminate the symbol leakge if you wish.
>>    
>>
>
>But you cannot avoid the public exposure of ZLIB_H, can you? And about
>the other macros, adding a series of #undefs at the bottom of zlib.h is
>unusual, and will incur a burden on maintenance. Did you have something
>else in mind?
>  
>

Nope, attribute won't help with ZLIB_H #define symbols, nor will 
attribute solve
any problem w/o gcc/binutils assistance.

73 de Jeff