This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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  (eggert@twinsun.com)

        * c-decl.c (store_parm_decls): Function prototypes now override
        old-style definitions if argument types disagree only because of
        promotions.

The earliest GCC version that supported glibc 2 for systems with the Linux 
kernel was 2.7.2.3 (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 
extension.)

-- 
Joseph S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]