gzopen64 implicitly converted to pointer

I'm not sure I agree with this patch. The point of _FILE_OFFSET_BITS=64 (at least as far as the standard C library goes) is to make the native interfaces be 64-bit clean, rather than to introduce additional *64 versions (which is the point of _LARGEFILE64_SOURCE), so this seems to make zlib.h vary from standard practice.

 -- 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).

This bug was fixed in the package libpciaccess - 0.10.6-2ubuntu1

---------------
libpciaccess (0.10.6-2ubuntu1) karmic; urgency=low

  * work around zlib problem with 64 bit and implicit pointer
    coversions (LP: #402178)

 -- Michael Vogt <email address hidden> Mon, 24 Aug 2009 08:29:43 +0200

I withdraw my comments about zlib; see the comment in the Debian bug. AFAICS you can go ahead with this patch, although it would be worth confirming that it's the same as Mark Brown's patch.

This bug was fixed in the package zlib - 1:1.2.3.3.dfsg-13ubuntu2

---------------
zlib (1:1.2.3.3.dfsg-13ubuntu2) karmic; urgency=low

  * zlib.h:
    - add prototypes for the 64 bit functions if
      _FILE_OFFSET_BITS=64 is defined (LP: #402178)

 -- Michael Vogt <email address hidden> Mon, 24 Aug 2009 08:34:59 +0200

afaiui chromium developers more or less say we were wrong with this patch:

<fta> agl, http://paste.ubuntu.com/265190/
<fta> agl, i don't get why -D_FILE_OFFSET_BITS=64 alone doesn't work, the test is "#if defined(_LARGEFILE64_SOURCE) || _FILE_OFFSET_BITS == 64"
<agl> fta: I think the zlib header is in error
<agl> fta: the *64 functions and types are only enabled by _LARGEFILE64_SOURCE
<agl> fta: however, we have _FILE_OFFSET_BITS=64, which switches the normal functions to 64-bit mode
<agl> fta: but the zlib header is referencing off64_t even in the case that only _FILE_OFFSET_BITS=64 is defined

Is there another approach we could use?