On Mon, Aug 24, 2009 at 10:41:47AM +0100, Mark Brown wrote: > On Mon, Aug 24, 2009 at 10:33:39AM +0100, Colin Watson wrote: > > So my reading of this is that, if zlib is following the same scheme (and > > wouldn't anything else just be confusing?), then gzopen64 should only be > > defined if _LARGEFILE64_SOURCE is defined, and otherwise gzopen should > > just be straight 64-bit and gzopen64 should not be defined. Compare e.g. > > <stdio.h>. > > The problem is that with _FILE_OFFSET_BITS set to 64 zlib transparently > maps the vanilla calls to their 64 bit equivalents so that everything is > fine at link time but it does not prototype the 64 bit variants.
Right. The glibc-ish way to do this appears to be something like: #ifndef __USE_FILE_OFFSET64 ZEXTERN gzFile ZEXPORT gzopen OF((const char *, const char *)); #else # ifdef __REDIRECT ZEXTERN gzFile ZEXPORT __REDIRECT (gzopen, OF((const char *, const char *)), gzopen64); # else # define gzopen gzopen64 # endif #endif #ifdef __USE_LARGEFILE64 ZEXTERN gzFile ZEXPORT gzopen64 OF((const char *, const char *)); #endif Of course, this relies on the special stuff glibc does in <features.h> to define __USE_LARGEFILE64 depending on whether __REDIRECT is defined, so maybe making this work cross-platform is too hard (though you could use '#if defined(_LARGEFILE64_SOURCE) && !defined(__REDIRECT)' etc., and maybe test __GLIBC__ as well as __REDIRECT). It would be nice to be namespace-clean though ... -- Colin Watson [[email protected]] -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
