[Zlib-devel] Changing zconf.h (was: zlib-1.2.3-cos1)

[William A. Rowe, Jr.]

Cosmin Truta wrote:
> 
> - Shut up annoying VS2005 warnings about standard C deprecation [Rowe, Truta]
> - Swap the order of #include <stdio.h> and #include "zlib.h" in
>   gzio.c, example.c and minigzip.c [Truta]
> 
> Both of these changes are here because much of the standard C library
> is "deprecated" in Visual C++ 8.
> Andrei Polushin made a point that the modification in zconf.h has side
> effects, and it's better to resort to using macros in VC makefiles and
> project files.

Yes - if there were a private, uninstalled zprivate.h file that was not
distributed, source-macros are a healthy solution, but putting such
macros in the public headers is wrong for reasons identified.

> His point is valid indeed, but I regard that as a "feature" rather than
> a "side effect". I mean, since zlib inherently depends on the standard
> C library, and the latter gets "deprecated", it implies the former also
> should be "deprecated" until that dependency is removed. Which (I bet)
> won't happen. zlib demands standard C, and anyone who demands zlib
> should also demand standard C.

This whole line of c$@p of demanding C++ ISO functions is indeed foolish,
and when OSS builds on POSIX compilers and not MS compilers, I trust that
the OSS community will designate MS compilers as irrelevant.

> There's also the cosmetic point of putting all compiler and library
> hacks in zconf.h instead of scattering them across makefiles. And then
> there's the practical point that the change is done in one place
> (zconf.h) instead of synchronizing changes in win32/makefile.msc,
> projects/visualc, contrib/minizip, ... and any other makefiles and
> projects. Not to mention the possibility of getting them yet again out
> of sync.

No, I'd still disagree.  This as evil as #define _USE_LARGEFILES and the
related macros inside of zconf.h.  It will break apps.  As they are private
compiler symbols that are *noops* for the public included definitions, the
only sane way to accomodate these two defines is to put them in the project
make files.  Yes, more files are touched.

But -D'efining them in make/project files is *far* healthier than impacting
the compilation of consumer's modules.  So adding these in source files is
worse than doing nothing, which is the approach we should take if we won't
attack the problem properly.

Bill