This is the mail archive of the
mailing list for the glibc project.
Re: non-prototype function definitions
On Fri, 8 Mar 2013, Paul Eggert wrote:
> Since glibc doesn't preserve the second property, and hasn't preserved
> it for many years without anybody noticing or caring, it would make
> sense for us to replace the unprototyped definitions with prototyped ones
> -- at any rate, I'd rather do that than to try to document why they're
> still old-style....
More specifically, this extension (prototypes overriding old-style
definitions) is documented as far back as GCC 2.2.2, coming from:
Sun Mar 29 19:58:57 1992 Paul Eggert (email@example.com)
* c-decl.c (store_parm_decls): Function prototypes now override
old-style definitions if argument types disagree only because of
The earliest GCC version that supported glibc 2 for systems with the Linux
kernel was 184.108.40.206 (and that may just have been support for building
programs against glibc 2, not necessarily for building glibc 2 itself).
The i386-gnu target in GCC 2.6.3 was an a.out target (at least, a target
with underscore-prefixed symbols).
Thus, for any system supported by current glibc, any glibc version against
which binaries might have been compiled that are meant to be
ABI-compatible with current glibc would have been built with a version of
GCC with the extension in question - meaning that the use of old-style
function definitions in that version of glibc had no special ABI
properties, and so there are no such ABI properties to preserve that form
part of any ABI supported by current glibc.
(Whether there are in fact any requirements for prototyped arguments
narrower than int to be extended in a particular way when passed to a
function is depends on the processor-specific ABI - although a lot of ABIs
leave such issues unclear so both caller and callee end up doing the same
Joseph S. Myers