void main()

[Karl Heuer]

In article <374 at helens.Stanford.EDU> mike at relgyro.STANFORD.EDU (Mike Macgirvin) writes:
>OK, this thing has my head spinning. I use Microsoft 'C' with full
>warnings. I do something easy like:
>	int main(void) { ... exit(0); }
>And the darn thing complains that I'm not returning a value.
>So in order to make the compiler shut up, I have to:
>	int main(void) { ... exit(0); /* NOTREACHED */ return (0); }
>[Which is overkill, and *creates* warnings on other compilers.]

I asked X3J11 to bless `void main()' (it shouldn't be any more difficult than
supporting both `int main(void)' and `int main(int, char **)'), but the
proposal was rejected, alas.

You're right; the second solution is overkill.  The correct solution is
something like:
	#include <stdlib.h>	/* for exit() */
	int main(void) { ... exit(0); /* NOTREACHED */ }
(or the same without the word "int" in front; this may make a difference).

If the compiler believes that main() is falling off the end, then it is
ignorant of the fact that exit() doesn't return, and if the implementation
doesn't provide a path to convey such facts, it shouldn't be trying to issue
warnings about it.

If the compiler realizes that main() doesn't return, but it doesn't like the
mismatch between the declared type "int" and the actual type "nonreturning",
then it is ignorant of the fact that this is a quite legal thing to do, and
even if it wants to warn about it in general, it ought to make a special case
for main().

If the vendor tells you that you should use return instead of exit to avoid
the problem, then the vendor is ignorant of the fact that many of us have
reasons to prefer exit(), and may well be more inclined to switch vendors than
to switch coding styles just to agree with the vendor's misguided notion of
correctness.

Karl W. Z. Heuer (ima!haddock!karl or karl at haddock.isc.com), The Walking Lint
(I *do* have reasons for using exit().  The reasons for using return are about
equal, and there's not a whole lot of point debating them.)