Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!cmcl2!yale!husc6!panda!genrad!decvax!watmath!atbowler
From: atbowler@watmath.UUCP (Alan T. Bowler [SDG])
Newsgroups: net.lang.c
Subject: Functions that never return
Message-ID: <3274@watmath.UUCP>
Date: Sat, 20-Sep-86 04:56:43 EDT
Article-I.D.: watmath.3274
Posted: Sat Sep 20 04:56:43 1986
Date-Received: Sat, 20-Sep-86 20:47:32 EDT
References: <1074@dataio.UUCP> <86900032@haddock>
Reply-To: atbowler@watmath.UUCP (Alan T. Bowler [SDG])
Organization: U of Waterloo, Ontario
Lines: 30

In article <86900032@haddock> you write:
>
>Note: 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.  I haven't
>changed my mind; I just want to point out some possibilities.
>
There are library functions "exit", "longjmp", "abort" that never
return.  Most implementations will have quite a few more,
and using these users will normally construct a number of others.
A larger program is very likely to have several error handlers
that print a message, do some cleanup and longjmp back to
a good restart point.
   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.
2) It is compatible with the existing language
3) It is reasonably obvious what it means
4) The compiler gets the optimizing hint it needs
   without requiring a flow analysis that goes outside the
   function boundaries (i.e. you don't have to sacrifice
   separate compilation to have an optimising compiler take
   advantage of it).
5) On a similar note it gets rid of the damned 
   /*NOTREACHED*/
   by associating the property of not returning with
   the function instead of with every call to the function.