[Zlib-devel] TR: the win32\Makefile.msc diff

[William A. Rowe Jr.]

On 3/14/2010 11:45 AM, Mark Adler wrote:
> Gilles,
> 
> On Mar 14, 2010, at 1:18 AM, Gilles Vollant wrote:
>> http://gvollant.free.fr/newprj_i64.zip
>> which add a define in contrib/vstudio/vc9 to have true 64 bits function like crc32_combine64
>> was not applied
> 
> I believe that your changes are incomplete, since in order to use the library, zlib.h or zconf.h needs to be modified to provide the off64_t data type (as __int64).  In any case, I am reluctant to include the _LARGEFILE64_SOURCE;off64_t=__int64;lseek64=_lseeki64 changes in this version.  A great deal of thought went into the LFS (Large File Summit) definition for Unix systems, in order to avoid binary compatibility issues.  I think it will take a little while to iron out those issues for zlib on Windows, so I would like to defer the implementation of 64-bit support for Windows to the next version.

I share the same concern with respect to non-Windows builds, however.

Looking at the compiler path in zconf.h, for all platforms who don't arrive
at a valid or recognized mapping of gzfoo64() functions (such as windows, and older
32 bit unix platforms), those functions should not have been allowed to compile at all.

This is easily recognized, when the build stumbles upon "no previous declaration
for gzseek64" etc.  I'm still not sure this was entirely thought out, and while
win32 won't export those dynamic symbols, they will still be offered from unix
dynamic libs, and the static libraries of all flavors.

I'm afraid that testers have equated compile/run success with gzfunc64 bit success,
and the two aren't equivilant.  A simple (sizeof(z_off64_t) == 8) test would suffice,
but sadly that doesn't work in a preprocessor context :(