Rants about void main seem archaic, unjustified, and pretentious.
And the validity of "void main" doesn't depend on whether the system uses exit statuses. An implementation may accept forms of main other than the ones defined by the language, including "void main()" -- but if it doesn't, the behavior of such a program is undefined.
The rules are different for freestanding implementations, which are generally for embedded systems; for such systems, the program entry point is entirely implementation-defined, and might not even be called "main". But for hosted implementations, there's no advantage at all in using "void main" vs. the correct "int main(void)".
Interesting. I wonder why gcc does it that way.
> And the validity of "void main" doesn't depend on whether the system uses exit statuses. An implementation may accept forms of main other than the ones defined by the language, including "void main()" -- but if it doesn't, the behavior of such a program is undefined.
I don't think we're disagreeing. I'm saying that "void main" is never preferable to "int main", and the only time it's equal to "int main" is if you're writing code specific to an implementation for which "void main" is not undefined and which lacks exit statuses, making any return statement in "int main" equivalent to returning from "void main".
> But for hosted implementations, there's no advantage at all in using "void main" vs. the correct "int main(void)".
Agreed. That's why it makes no sense for textbooks to teach void main.
void main(void) { init(); for(;;) { web_tick(); serial_tick(); tcp_tick(); etc. } }
An example is the horrible Dynamic C compiler from z-world (or digi as they are now called). Guys who complain about "violating standards" clearly haven't worked in diverse enough fields on broken, shitty and half-standard compilers ;)