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