On Sun, Aug 09, 2009 at 11:30:33AM +0100, Mark Brown wrote:
> On Sat, Aug 08, 2009 at 10:17:40PM +0200, Julien Cristau wrote:
> > is there any news on this bug (zlib.h only defining a prototype for
> > gzopen64 if _LARGEFILE64_SOURCE is defined)? I noticed some warnings
> > related to gzopen64 when building libpciaccess on some archs, and just
> > found this bug.
>
> I believe the patch (or something like it) has been applied upstream and
> will be included in the next release. Upstream have a somewhat erratic
> release schedule and no public VCS, unfortunately.
Defining gzopen64 when _FILE_OFFSET_BITS=64 seems just wrong. Here are
the standard semantics of _LARGEFILE64_SOURCE and _FILE_OFFSET_BITS=64,
from 'info libc':
-- Macro: _LARGEFILE64_SOURCE
If you define this macro an additional set of functions is made
available which enables 32 bit systems to use files of sizes beyond
the usual limit of 2GB. This interface is not available if the
system does not support files that large. On systems where the
natural file size limit is greater than 2GB (i.e., on 64 bit
systems) the new functions are identical to the replaced functions.
The new functionality is made available by a new set of types and
functions which replace the existing ones. The names of these new
objects contain `64' to indicate the intention, e.g., `off_t' vs.
`off64_t' and `fseeko' vs. `fseeko64'.
This macro was introduced as part of the Large File Support
extension (LFS). It is a transition interface for the period when
64 bit offsets are not generally used (see `_FILE_OFFSET_BITS').
-- Macro: _FILE_OFFSET_BITS
This macro determines which file system interface shall be used,
one replacing the other. Whereas `_LARGEFILE64_SOURCE' makes the
64 bit interface available as an additional interface,
`_FILE_OFFSET_BITS' allows the 64 bit interface to replace the old
interface.
If `_FILE_OFFSET_BITS' is undefined, or if it is defined to the
value `32', nothing changes. The 32 bit interface is used and
types like `off_t' have a size of 32 bits on 32 bit systems.
If the macro is defined to the value `64', the large file interface
replaces the old interface. I.e., the functions are not made
available under different names (as they are with
`_LARGEFILE64_SOURCE'). Instead the old function names now
reference the new functions, e.g., a call to `fseeko' now indeed
calls `fseeko64'.
This macro should only be selected if the system provides
mechanisms for handling large files. On 64 bit systems this macro
has no effect since the `*64' functions are identical to the
normal functions.
This macro was introduced as part of the Large File Support
extension (LFS).
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>.
Perhaps this is really a bug in the callers?
--
Colin Watson [cjwat...@debian.org]
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
