functions that don't return

[karl at haddock]

hadron!jsdy (Joe Yao) writes:
>Using 'return' from main() is the preferred way to exit according
>to System V lint (which complains otherwise).

The reason is simply that lint doesn't know about exit() -- it's just another
function as far as it knows.  The warning is not in any way an endorsement
of return over exit, as lint will be equally happy if you put a goto at the
bottom of main() and call exit() in the middle somewhere.

>I've preferred it myself, for years before, because I've viewed exit() as a
>glitch in a smooth mental model of the invocation and return of routines.

I used to prefer return for the same reasons (actually I preferred exit()
before that, because it works even if your local crt0 ignores the result of
main -- as ours did for a while).  Now I've reverted to exit(), because I
consider it a better model for error handling: "fprintf(stderr, usage); \
exit(1);" is more meaningful to me than "... return (1);" and won't break
if the code segment moves into a subroutine.  At the bottom of main(), I now
tend to use exit() again (throwing in a /*NOTREACHED*/ and cussing under my
breath), for reasons I can't explain well.

There are three possible models for the crt0/main interface:  main() could be
int ("exit(main())"), void ("main(); exit(0)"), or dead ("main(); HALT").  I
kind of like the last idea; it requires the user to explicitly call exit(),
but it makes all main programs equivalent.  (Including those which neither
return nor exit, for which the declaration "int main()" looks silly.)

Karl W. Z. Heuer (ima!haddock!karl or karl at haddock.isc.com), The Walking Lint