This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] Make _FILE_OFFSET_BITS=64 default.
- From: Paul Eggert <eggert at cs dot ucla dot edu>
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: libc-alpha at sourceware dot org
- Date: Fri, 14 Mar 2014 14:30:21 -0700
- Subject: Re: [RFC] Make _FILE_OFFSET_BITS=64 default.
- Authentication-results: sourceware.org; auth=none
- References: <1393521776-1102-1-git-send-email-reprofy at etersoft dot ru> <26837730 dot jZzKCPMtpS at vapier> <Pine dot LNX dot 4 dot 64 dot 1403131254080 dot 4888 at digraph dot polyomino dot org dot uk> <1818532 dot 29kOdgNHi0 at vapier> <5322A4AC dot 2050104 at cs dot ucla dot edu> <20140314181837 dot GJ184 at brightrain dot aerifal dot cx>
On 03/14/2014 11:18 AM, Rich Felker wrote:
>zlib's zlib.h attempts to work around the glibc problems with
>_FILE_OFFSET_BITS, and its workaround would need adjusting if glibc
>changed the default.
Can you explain in more detail?
It's pretty obscure, and I expect we don't need to worry about it. As I
understand it, the problem affects only applications that use
-D_FILE_OFFSET_BITS=32. I don't know of any (who would want to do
that?!), but there it is. zconf.h does this:
#if defined(_LFS64_LARGEFILE) && _LFS64_LARGEFILE-0
# define Z_LFS64
#endif
...
#if defined(_FILE_OFFSET_BITS) && _FILE_OFFSET_BITS-0 == 64 &&
defined(Z_LFS64)
# define Z_WANT64
#endif
and Z_WANT64's only use is in zlib.h, in the code at the end of this
email. This causes zlib to use a workaroundsomething like glibc's when
_FILE_OFFSET_BITSis explicitly defined to be 64. zlib itself is
compiled with no _FILE_OFFSET_BITS setting (it uses z_off64_t, lseek64
etc. internally), so if glibc changes the _FILE_OFFSET_BITS default to
64, zlib would then support only 64-bit off_t, and zlib's workaround
would break programs compiled with -D_FILE_OFFSET_BITS=32. If zlib
wanted to continue to support 32-bit-only off_t, it'd need to compile
itself with -D_FILE_OFFSET_BITS=32, and tweak zconf.h and zlib.h a bit.
My guess is that zlib wouldn't bother. I know zlib's maintainer and so
could ask him, if there's interest.
#if !defined(ZLIB_INTERNAL) && defined(Z_WANT64)
# ifdef Z_PREFIX_SET
# define z_gzopen z_gzopen64
# define z_gzseek z_gzseek64
# define z_gztell z_gztell64
# define z_gzoffset z_gzoffset64
# define z_adler32_combine z_adler32_combine64
# define z_crc32_combine z_crc32_combine64
# else
# define gzopen gzopen64
# define gzseek gzseek64
# define gztell gztell64
# define gzoffset gzoffset64
# define adler32_combine adler32_combine64
# define crc32_combine crc32_combine64
# endif
# ifndef Z_LARGE64
ZEXTERN gzFile ZEXPORT gzopen64 OF((const char *, const char *));
ZEXTERN z_off_t ZEXPORT gzseek64 OF((gzFile, z_off_t, int));
ZEXTERN z_off_t ZEXPORT gztell64 OF((gzFile));
ZEXTERN z_off_t ZEXPORT gzoffset64 OF((gzFile));
ZEXTERN uLong ZEXPORT adler32_combine64 OF((uLong, uLong, z_off_t));
ZEXTERN uLong ZEXPORT crc32_combine64 OF((uLong, uLong, z_off_t));
# endif
#else
ZEXTERN gzFile ZEXPORT gzopen OF((const char *, const char *));
ZEXTERN z_off_t ZEXPORT gzseek OF((gzFile, z_off_t, int));
ZEXTERN z_off_t ZEXPORT gztell OF((gzFile));
ZEXTERN z_off_t ZEXPORT gzoffset OF((gzFile));
ZEXTERN uLong ZEXPORT adler32_combine OF((uLong, uLong, z_off_t));
ZEXTERN uLong ZEXPORT crc32_combine OF((uLong, uLong, z_off_t));
#endif