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

[Cosmin Truta]

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.


Best regards,
Cosmin