gzopen64 implicitly converted to pointer
Bug #402178 reported by
LaMont Jones
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
libpciaccess (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Karmic |
Fix Released
|
High
|
Unassigned | ||
zlib (Debian) |
Fix Released
|
Unknown
|
|||
zlib (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Karmic |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Function `gzopen64' implicitly converted to pointer at ../../src/
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://
[2] http://
Changed in libpciaccess (Ubuntu Karmic): | |
importance: | Undecided → High |
milestone: | none → karmic-alpha-6 |
status: | New → Triaged |
Changed in zlib (Debian): | |
status: | Unknown → Confirmed |
Changed in zlib (Debian): | |
status: | Confirmed → Fix Released |
To post a comment you must log in.
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 OFFSET_ BITS').
extension (LFS). It is a transition interface for the period when
64 bit offsets are not generally used (see `_FILE_
-- Macro: _FILE_OFFSET_BITS SOURCE' makes the FILE_OFFSET_ BITS' allows the 64 bit interface to replace the old
This macro determines which file system interface shall be used,
one replacing the other. Whereas `_LARGEFILE64_
64 bit interface available as an additional interface,
`_
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 LARGEFILE64_ SOURCE' ). Instead the old function names now
replaces the old interface. I.e., the functions are not made
available under different names (as they are with
`_
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).