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

[Xin LI]

On Fri, Mar 26, 2010 at 1:06 PM, Mark Brown <broonie at sirena.org.uk> wrote:
>> > _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.
>
>> Or perhaps during zlib's ./configure?  I think once zlib binary has
>> been built, the zlib.h (zconf.h actually) installed together with it
>> should be somewhat "fixed configuration" instead of depending system
>> headers or arbitrary user-defined macros.
>
> Sadly they're not intended to be fixed at system build time, the
> intended use is dynamic at application compile time.

But this *only* happens on systems that provide one interface that is
limited to 32 bit and another limited to 64 bit for the same
functionality.

What will happen if, say, zlib is compiled on one of these platforms
without _FILE_OFFSET_BITS defined, and a program happens to compile
with _FILE_OFFSET_BITS == 64?  I think this would just introduce more
confusions than usefulness it brought.

>> Note that _FILE_OFFSET_BITS nor _LARGEFILE_64_SOURCE are part of LFS
>> and is not supposed to appear on any operating systems other than
>> Linux, thus, portable programs should not depend on these macros
>> unconditionally IMHO.
>
> They're not Linux specific, they're also supported on some other
> operating systems that have done the same transition - Solaris is one
> IIRC.  I'm pretty sure they come from SuS originally but I'd have to go
> check.

No, they are not defined in neither SuS nor IEEE Std 1003.1-2008.  I
found an Open Group white paper [1] on this and am sure that POSIX is
not even trying to mandate the use of these macros.

[1] http://opengroup.org/platform/lfs.html

Cheers,
-- 
Xin LI <delphij at delphij.net> http://www.delphij.net