http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076

--- Comment #10 from joseph at codesourcery dot com <joseph at codesourcery dot 
com> 2010-11-04 13:54:58 UTC ---
On Thu, 4 Nov 2010, rguenth at gcc dot gnu.org wrote:

> Joseph, does C really distinguish between
> 
> int foo()
> {
> }
> 
> and
> 
> int foo(void)
> {
> }
> 
> ?  That is, are they not the same when in a function definition context
> (as opposed to declaration context)?

Yes, they are different.  The first definition does not give foo a type 
that includes a prototype for subsequent references to that function in 
the translation unit.  Thus a subsequent function may call foo with 
arguments - this is undefined behavior only at runtime, if the call is 
executed, not at compile time - and although the standard is less clear 
(see DR#316) that pointers to foo can be stored in pointers to other 
prototyped function types (with int return type, not variadic) without 
casts.

> It would be nice if the C frontend would handle them the same (thus,
> make it not varargs).

int foo() certainly isn't varargs; unprototyped function types are always 
incompatible with variadic function types.

You could lower the function to have a type with (void) at some point - 
modulo any differences there might be in how they are supposed to be 
represented in debug info - but then you might need to fix up the 
conversions between types that are now incompatible, and to convert calls 
with bad arguments to use __builtin_trap (after evaluating all the 
arguments, in case one of the arguments calls exit, of course - the 
undefined behavior is only at the point of the call, after evaluation of 
all the arguments and the function designator).

Reply via email to