Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!think!ima!haddock!karl
From: karl@haddock
Newsgroups: net.lang.c
Subject: Re: Functions that never return
Message-ID: <86900064@haddock>
Date: Mon, 22-Sep-86 09:55:00 EDT
Article-I.D.: haddock.86900064
Posted: Mon Sep 22 09:55:00 1986
Date-Received: Mon, 22-Sep-86 21:38:09 EDT
References: <3274@watmath.UUCP>
Lines: 42
Nf-ID: #R:watmath.UUCP:3274:haddock:86900064:000:1803
Nf-From: haddock!karl    Sep 22 09:55:00 1986


watmath!atbowler writes:
>In article <86900032@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@haddock.isc.com), The Walking Lint