Functions that never return

[karl at haddock]

watmath!atbowler writes:
>In article <86900032 at haddock> [haddock!karl] writes:
>>In my earlier posting I came to the tentative conclusion that the "dead
>>function" concept (a function which never returns, e.g. exit) would probably
>>not be sufficiently useful to be worth adding a new builtin type.
>
>There are library functions "exit", "longjmp", "abort" that never return...
>On the observation that this is a "goto" type of action why not just recycle
>the "goto" keyword and allow it in function type declarations. e.g.
>    extern goto exit(int);
>
>1) It does not require a new keyword.

If I had to choose between adding a new keyword vs. using the same word for
flow-control and type-specification, I'd choose the former.  I'm still
urinated off about the double meanings of "static" and "break".

>2) It is compatible with the existing language

Adding a new keyword will not obsolete any programs except those that use it
as an identifier.  Such programs are easy to upgrade ("#define dead id_dead"
is almost sufficient, if you're lazy).  Conversely, programs written for the
new language can be downgraded for old compilers with "#define dead void" --
no such simple fix is available if "goto" acquires new semantics.

>3) It is reasonably obvious what it means

I'll grant that.

>4) The compiler gets the optimizing hint it needs ...

True with either "goto" or "dead", of course.  This, and Say-What-You-Mean,
are (I think) the only arguments in favor of adding the feature at all.

>5) On a similar note it gets rid of the damned /*NOTREACHED*/

As I pointed out before, this can be handled by making lint smarter:
"void exit(int) { for (;;); }" should suffice, and doesn't even require a
new lint-comment.

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