[Zlib-devel] Explicit link to libc

[John Bowler]

From: Mark Adler
>What about lseek() and off_t?

POSIX 1003.1 2.6 says off_t is "used for file sizes" and "defined by the implementation".  Windows NT, IRC, always supported 64bit sized files, but no longer supports POSIX 1003.1.  The Microsoft compiler (Visual Studio) simply makes off_t 32 bits, 'long'; this is what the POSIX standard pretty explicitly suggests.  The invented API _lseeki64 takes, and returns a 64bit (signed) offset.

By analogy with Microsoft fseek, lseek will fail if called when the file position is beyond the 32 bit limit, but the MS documentation doesn't say this explicitly.

The documentation does mention off_t, it's here:

http://msdn.microsoft.com/en-us/library/323b6b3k.aspx

The type is always typedefed 'long' (this is 32 bit only free Visual Studio, but this is an FS issue, so it shouldn't matter.)  When _POSIX_ is defined it comes from <sys/types.h>, otherwise it comes from <wchar.h>.  The definition isn't available if __STDC__ is defined (of course), but _off_t is always defined.

fpos_t, on the other hand, does what you want so long as _POSIX_ is not defined, however it isn't possible to do math on it.  fpos_t is defined by ANSI-C and should be completely portable, but Visual Studio is zapping the definition when _POSIX_ gets defined to 'long', I don't know why; this seems totally broken.

POSIX 1003.1 is quite explicit about off_t, B.2.6: "This type is used only in lseek() 6.5.3, fcntl() 6.5.2, and <sys/stat.h> 5.6.1.  Many implementations would have difficulties if it were defined as anything other than 'long'.  The Working Group realizes that requiring an integral type limits the capabilities of lseek() to four gigabytes.  See lread() B.6.4.  Also, the C Standard supplies routines that use larger types: see fgetpos() B6.5.3 and fsetpos() B6.5.3."

So... maybe zlib should give up on this; just use 'long' in gzseek and provide gzsetpos and gzgetpos.

John Bowler <jbowler at acm.org>