Ubuntu

gzopen64 implicitly converted to pointer

Reported by LaMont Jones on 2009-07-21
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
libpciaccess (Ubuntu)
High
Unassigned
Karmic
High
Unassigned
zlib (Debian)
Fix Released
Unknown
zlib (Ubuntu)
Undecided
Unassigned
Karmic
Undecided
Unassigned

Bug Description

Function `gzopen64' implicitly converted to pointer at ../../src/common_device_name.c:62

Our automated build log filter[1] detected the problem(s) above that will
likely cause your package to segfault on 64-bit architectures (where the
size of a pointer is greater than the size of an integer.)

This is often due to a missing function prototype definition.
For more information, see [2].

Since use of implicitly converted pointers is always (eventually
and/or itermittantly) fatal to the application, they are errors.
Please correct them for your next upload.

[1] http://people.debian.org/~dannf/check-implicit-pointer-functions
[2] http://wiki.debian.org/ImplicitPointerConversions

Steve Langasek (vorlon) on 2009-07-22
Changed in libpciaccess (Ubuntu Karmic):
importance: Undecided → High
milestone: none → karmic-alpha-6
status: New → Triaged
Michael Vogt (mvo) wrote :
Changed in zlib (Debian):
status: Unknown → Confirmed
Colin Watson (cjwatson) wrote :

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

Launchpad Janitor (janitor) wrote :

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

Changed in libpciaccess (Ubuntu Karmic):
status: Triaged → Fix Released
Colin Watson (cjwatson) wrote :

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.

Launchpad Janitor (janitor) wrote :

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

Changed in zlib (Ubuntu Karmic):
status: New → Fix Released
Alexander Sack (asac) wrote :

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?

Changed in zlib (Debian):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.