[RFC] Reduce namespace pollution on zlib.h

[Jung-uk Kim]

On Friday 26 March 2010 02:34 pm, Xin LI wrote:
> Hi,
>
> The recent zlib import has added some assumption that
> _LARGEFILE_64_SOURCE is only defined on systems with System V style
> *64 interface.  Moreover, I have added _FILE_OFFSET_BITS = 64
> definition into zconf.h so that it would pick up the 64 bit
> interface properly.

I guess you meant _LARGEFILE64_SOURCE. :-)

Last night I had so much trouble rebuilding ports because many ports 
have bogus assumption that _LARGEFILE64_SOURCE is required for 
supporting large files.  It seems _LARGEFILE64_SOURCE is only needed 
for OSes where sizeof(off_t) is 4 and it provides additional 
functions such as fseeko64() and ftello64(), which takes off64_t type 
as an argument or returns off64_t type.  However, _FILE_OFFSET_BITS = 
64 means sizeof(off_t) is 8 but you have to avoid off64_t, fseeko46
(), ftello64(), etc, etc...

http://www.gnu.org/s/libc/manual/html_node/Feature-Test-Macros.html

If I read them all correctly, it means (on 32-bit platforms):

Case  M1 M2 M3  T1 T2  F1 F2  Note
----------------------------------
   1   N  N  N   4  N   N  N
   2   N  N  Y   8  N   N  N
   3   N  Y  N   4  ?   ?  ?   [1]
   4   N  Y  Y   8  ?   ?  ?   [1]
   5   Y  N  N   4  ?   ?  ?   [2]
   6   Y  N  Y   8  N   Y  N   [3]
   7   Y  Y  N   4  Y   Y  Y   [4]
   8   Y  Y  Y   8  Y   Y  Y   [5]

M1: _LARGEFILE_SOURCE 		(N: undefined, Y: defined)
M2: _LARGEFILE64_SOURCE 	(N: undefined, Y: defined)
M3: _FILE_OFFSET_BITS		(N: undefined or 32, Y: 64)
T1: off_t			(4: 32-bit, 8: 64-bit)
T2: off64_t			(N: unavail, Y: avail)
F1: fseeko() and ftello()	(N: unavail, Y: avail)
F2: fseeko64() and ftello64()	(N: invisible, Y: visible)

[1] Impossible.  Some people argue that _LARGEFILE64_SOURCE must imply 
_LARGEFILE_SOURCE.
[2] Impossible.  Some people argue that _LARGEFILE_SOURCE must imply 
_LARGEFILE64_SOURCE and/or _FILE_OFFSET_BITS=64.
[3] All BSDs (including Darwin) and the future of Linux. ;-)
[4] Transitional according to the GNU libc manual.
[5] It is wrong but I think it exists.

So, zlib developers wanted to distinguish #6 from #7 and #8.  I think 
we can do something like Apple did:

http://trac.macports.org/changeset/65036

Basically _LARGEFILE64_SOURCE is completely unnecessary and evil for 
all BSDs.

> This unfortunately could cause some namespace pollution.  As such,
> I would propose the attached changes to zlib headers:
>
> zconf.h:
>  * If _LARGEFILE_64_SOURCE is defined, set
> __FreeBSD_LARGEFILE_64_SOURCE and undefine it, as it would break
> zlib.h
>  * If _FILE_OFFSET_BITS is undefined, set
> __FreeBSD_FILE_OFFSET_BITS and define it as 64.
>
> zlib.h:
>  * If __FreeBSD_LARGEFILE_64_SOURCE is defined and
> _LARGEFILE_64_SOURCE undefined, undefine
> __FreeBSD_LARGEFILE_64_SOURCE and define _LARGEFILE_64_SOURCE.
>  * If __FreeBSD_FILE_OFFSET_BITS is defined and _FILE_OFFSET_BITS
> is defined, undefine both.
>
> This approach is kind of mess, though, but would avoid massive
> changes which I'd propose for next zlib release.
>
> Comments?  Objections?

Please don't do that.  I think we just have to fix individual ports 
for now, something like this:

http://trac.macports.org/changeset/64855

It seems the author of zlib suggested it is better solution, actually:

http://trac.macports.org/ticket/24061

FYI, there is a web site dedicated for this issue:

http://ac-archive.sourceforge.net/largefile/index.html

Yes, I had to google a lot last night... :-(

Jung-uk Kim