No.
According to the normative wording of the standard, a definition
using empty parentheses without the void keyword is not one of the
forms that must be accepted, and strictly speaking the behavior of
such a program is undefined.
Reference:
N1570
section 5.1.2.2.1. (The published 2011 ISO C standard, which is not
freely available, has the same wording as the N1570 draft.)
Paragraph 1 says:
The function called at program startup is named main. The implementation declares no
prototype for this function. It shall be defined with a return type of int and with no
parameters:
int main(void) { /* ... */ }
or with two parameters (referred to here as argc and argv, though any names may be
used, as they are local to the function in which they are declared):
int main(int argc, char *argv[]) { /* ... */ }
or equivalent; or in some other implementation-defined manner.
The use of the word "shall" outside a constraint means that any
program that violates it has undefined behavior. So if, for example, I write:
double main(unsigned long ocelots) { return ocelots / 3.14159; }
a conforming compiler isn't required to print a diagnostic, but it's
also not required either to compile the program or, if it does compile
it, to have it behave in any particular manner.
If int main() were equivalent to int main(void), then it
would be valid and portable to any conforming hosted implementation.
But it's not equivalent.
int main(void) { }
provides both a declaration (in this case, a prototype) and a
definition. The declaration, by using the void keyword, specifies that the function has no parameters. The definition specifies the same thing.
If I instead write:
int main() { }
then I'm using an old-style declaration and definition. (Such
declarations and definitions are obsolescent, but they're still
part of the language definition, and all conforming compilers must
still support them.)
As a declaration, it doesn't specify the number or type(s) of arguments
expected by the function. As a definition, it defines no parameters,
but compilers needn't use that information to diagnose incorrect calls.
DR #317 includes the C standard committee's 2006 ruling that a definition with () does not provide a prototype equivalent to one with (void) (thanks to hvd for finding that reference).
C allows main to be called recursively. Suppose I write:
int main(void) {
if (0) {
main(42);
}
}
The visible prototype int main(void) specifies that main takes
no arguments. A call that attempts to pass one or more arguments
violates a constraint, requiring a compile-time diagnostic.
Or suppose I write:
int main() {
if (0) {
main(42);
}
}
If the call main(42) were executed, it would have undefined behavior
-- but it doesn't violate a constraint, and no diagnostic is required.
Since it's protected by if (0), the call never happens, and
the undefined behavior never actually occurs. If we assume that
int main() is valid, then this program must be accepted by any
conforming compiler. But because of that, it demonstrates that
int main() is not equivalent to int main(void), and therefore
is not covered by 5.1.2.2.1.
Conclusion: Following the wording of the standard, an
implementation is permitted to document that int main() { } is
permitted. If it doesn't document it, it's still permitted to accept
it without complaint. But a conforming compiler may also reject
int main() { }, because it is not one of the forms permitted by
the standard, and its behavior is therefore undefined.
But there's still an open question: Was that the intent of the authors
of the standard?
Prior to the publication of the 1989 ANSI C standard, the void
keyword did not exist. Pre-ANSI (K&R) C programs would define main
either as
main()
or as
int main()
A major goal of the ANSI standard was to add new features (including
prototypes) without breaking existing pre-ANSI code. Stating that
int main() is no longer valid would have violated that goal.
My suspicion is that the authors of the C standard did not intend
to make int main() invalid. But the standard as written does not
reflect that intent; it at least permits a conforming C compiler
to reject int main().
Practically speaking, you can almost certainly get away with it.
Every C compiler I've ever tried will accept
int main() { return 0; }
without complaint, with behavior equivalent to
int main(void) { return 0; }
But for a variety of reasons:
- Following both the letter and the intent of the standard;
- Avoiding the use of an obsolescent feature (a future standard could remove old-style function definitions);
- Maintaining good coding habits (the difference between
() and (void) is important for functions other than main that are actually called by other functions).
I recommend always writing int main(void) rather than int main().
It states the intent more clearly, and you can be 100% sure that your
compiler will accept it, rather than 99.9%.
