functions that don't return

[Gary M. Samuelson]

In article <86900070 at haddock> karl at haddock writes:

Re 'exit()' versus 'return' to leave main():
>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.

Interesting.  I started using 'return' instead of 'exit()' so that the
code segment wouldn't break if moved into a subroutine -- to be more
precise, so that I could call 'main()' as a subroutine (recursion
being occasionally useful).  Anyone else do this?

>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 suppose this is an operating system (environment) issue.  Assuming
UNIX, the first model is the only correct one.  If you're not assuming
UNIX, what is 'crt0'?

>I
>kind of like the last idea; it requires the user to explicitly call exit(),
>but it makes all main programs equivalent.

It only makes all main programs equivalent by requiring that they all
be written the same way.  I don't see the advantage.  Assuming a
multiuser environment, it wouldn't be a very good idea at all.  ("Why
is the system hung?"  "Oh, someone ran the 'hello, world' program again.")

>(Including those which neither
>return nor exit, for which the declaration "int main()" looks silly.)

Routines which do not return or exit should be declared 'void'
(or 'dead' -- if that were to be added to the language, which I
wouldn't recommend, but wouldn't fight either).

Gary Samuelson