Richard Heathfield said:
Keith Thompson said:
I remember that this has come up before. I wasn't completely convinced
then, and I'm not completely convinced now.
A function definition that has no parameter list takes no parameters, and
is thus precisely equivalent to int main(void) in semantic terms. (Note
that we're not talking about mere definitions here.)
Since the Standard only requires of main that it be equivalent to int
main(void) or int main(int argc, char **argv), and since int main() is
equivalent to int main(void), it seems to me that int main() is perfectly
acceptable - to the compiler, at least, even though the stylist might
object.
<snip>
Reference: C99 5.1.2.2.1 Program startup
For this definition:
int main() { return 0; }
to be valid (by "valid" here, I mean that an implementation is
required to support it with well-defined behavior), it must be
"equivalent" to this definition, which is undeniably valid:
int main(void) { return 0; }
It's equivalent by itself, when considered only as a self-contained
function definition. However, the definition also provides a
*declaration*. I assert that the two definitions are *not*
equivalent, because they provide non-equivalent declarations.
Assume an implementation that does accept "int main() { return 0; }"
with the obvious meaning (this is allowed by the "or in some other
implementation-defined manner" clause if not by the "or equivalent"
clause). Or, if you prefer, assume that "int main() { return 0; }" is
valid. Then this program:
int main() { return 0; }
void foo(void) { main(42); }
is valid (the declaration of main requires an unspecified number and
type of arguments; the call to main would invoke undefined behavior if
it were executed, but it never is). But this program:
int main(void) { return 0; }
void foo(void) { main(42); }
violates the constraint in C99 6.5.2.2p2.
Therefore, a definition using "int main()" is not equivalent to one
using "int main(void)", and thus an implementation needn't support it.
Note that, assuming my reasoning is correct, "int main()" doesn't
violate any constraint. A program that uses it merely invokes
undefined behavior. As it happens, every implementation I know of
responds to this undefined behavior by quietly accepting the
definition.
I'm not convinced that this was the intent, and I'd be unsurprised to
find that the members of the committee either intended "int main()" to
be valid, or just didn't think about it.
Implementers can avoid the issue by accepting "int main()", and
programmers can avoid the issue by using not using "int main()", so
it's not a huge deal either way.
I see I posted a similar question to comp.std.c last July,
subject "Is 'int main() { /* ... */ }' valid?":
http://groups.google.com/group/comp.std.c/browse_frm/thread/fef53cc781d555a4/41630179750145a9
but re-reading that thread I see I was actually asking about a
different subtle issue.