This is the mail archive of the 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 03/08/13 13:43, Roland McGrath wrote:

>    Once upon a time, GCC would give you a warning or error about:
> 	extern void foo (char c);
> 	void
> 	foo (c)
> 	     char c;
> 	{
> 	  ...
> 	}
>    because the definition didn't really match the declaration.

Hoo boy!  I remember that.  That code doesn't conform to the C
standard, which is why GCC warned about it.  I fixed that in GCC many
years ago, by adding an extension to GNU C to allow the above
construction.  In the GNU extension, the old-style definition is
treated as if it were prototyped, if there's an earlier (and
compatible-enough) prototyped declaration for the same function.

For example, if you compile the following program with GCC:

double f (float c) { return c; }
double g (c) float c; { return c; }
double h (float);
double h (c) float c; { return c; }

F and H should compile to the same set of instructions, whereas G will
typically compile to something different.  A strict C compiler will
reject the program because H's declaration and definition don't match.

> We still would like to preserve these two properties in the API/ABI:
> that every public function has a prototype declaration in an installed
> header file; and that every function works correctly when called
> without a prototype declaration in scope.

Thanks for explaining things.  Oh my.  I wish Ulrich would have
explained this when I asked him about it years ago!  I would have told
him that glibc's approach doesn't preserve the second property,
because GCC treats the definition of FOO as if it were prototyped.  If
there is an ABI incompatibility between a prototyped definition and an
unprototyped call, the call won't work; and if there isn't an
incompatibility, the call would work just as well if glibc used
prototypes everywhere.

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

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