[Zlib-devel] [Fwd: Two buglets in zlib-1.2.0.7] [+PATCH]

[Jeff Johnson]

Cosmin Truta wrote:

>Jeff Johnson wrote:
>
>  
>
>>The other problems has to do with s/_ZLIB_H/ZLIB_H/ which breaks a
>>fragile (imho) test for internal vs. external zlib being used. I've
>>reverted to the zlib-1.1.4 define for the moment, will be perfectly
>>happy to make the test in R more robust
>>    #if defined(_ZLIB_H) || defined(ZLIB_H)
>>should fix the fragile test if there are reasons to change the
>>convention.
>>    
>>
>
>Since neither _ZLIB_H nor ZLIB_H are present in the zlib documentation,
>users should assume they do NOT exist. They are internals that we cannot
>hide because of the well-known problem of the C programming language:
>global namespace pollution caused by macros.
>
>Yet, they remain internals, and we are not trying to support them
>(preserve compatibility, etc.) in any way. The same comment applies to
>all other undocumented hacks present in zlib.h or zconf.h (ZEXPORT,
>UNALIGNED_OK, SYS16BIT, etc.)
>
>If a user wants to ensure that zlib.h is #included, s/he only has to
>write #include "zlib.h". Including zlib.h multiple times should not be
>an issue ... unless:
>
>If a user has setup problems that allow the inclusion of zlib.h from
>1.1.4 and another zlib.h from 1.2.0, and both headers get included, then
>a compiler error will be triggered (e.g. z_stream_s defined twice).
>This will offer the occasion to fix the zlib.h setup.
>
>If a user wants to know if zlib.h was included, without necessarily
>including it (although I can't imagine why someone would do this), then
>s/he should check a public symbol like ZLIB_VERSION, instead of _ZLIB_H
>or ZLIB_H.
>
>  
>

Sure. s/_ZLIB_H/ZLIB_H/ is  the easy problem, already taken care of.

73 de Jeff