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