[Zlib-devel] [PATCH] Avoid testing _LARGEFILE_64_SOURCE and _FILE_OFFSET_BITS directly

[Mark Brown]

On Fri, Mar 26, 2010 at 12:04:26PM -0700, Xin LI wrote:

> Here is a patch that avoids testing _LARGEFILE_64_SOURCE and
> _FILE_OFFSET_BITS directly in zlib.h.

Your MUA appears to have encoded this as a binary file which isn't
helpful for quoting - you might want to look at your MUA configuration.
Anyway...

> *BSDs (including Mac OS X) have 64-bit off_t from the day 1 as
> inherited from BSD Unix as I have verified from 44BSD's SCCS tree (the
> original change happened in revision 7.21 92/05/13 14:44:26 by
> mckusick).  Also, _LARGEFILE_64_SOURCE doesn't apply to us and
> _FILE_OFFSET_BITS is not defined on these platforms.

_FILE_OFFSET_BITS is not defined by the platform.  This is something
that can be defined during compilation to force off_t to be whatever the
value is, boiling down to a noop if off_t is 64 bit anyway.

If we're going to do a bodge here it should also be done on 64 bit
architectures in general since they will generally have started off with
64 bit off_t too.

> Unfortunately some third party programs defines _LARGEFILE_64_SOURCE
> when compiling on FreeBSD as a workaround, as reported by some Gentoo
> developers.  This would break zlib.h definations since zlib uses
> _LARGEFILE_64_SOURCE as an indicator of availability of *64 functions.

That's exactly what _LARGEFILE64_SOURCE means - it's a request to define
the extra 64 bit variants of the APIs.  zlib simply follows suit and
adds its own into the mix.  If it doesn't make those APIs available then
presumably these programs are just plain broken on the affected platforms
anyway since the underlying 64 bit I/O functions aren't available and
therefore can't be built and linked against.  Given that it's not clear
that ignoring it is ever the most sensible solution.

> The proposed change make zlib more platform neutral.  It introduces
> two namespaced macros: ZLIB_FILE_OFFSET_BITS and
> ZLIB_LARGEFILE_64_SOURCE.  For *BSD and Mac OS X,
> ZLIB_FILE_OFFSET_BITS would be defined as 64; for non-BSD platforms,
> ZLIB_FILE_OFFSET_BITS would be dependent of _FILE_OFFSET_BITS.
> used by third parties).

TBH I'm really surprised any of the programs that trigger issues (what
exactly are the issues?) here ever work.