Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!caip!princeton!allegra!ulysses!burl!clyde!watmath!rbutterworth
From: rbutterworth@watmath.UUCP (Ray Butterworth)
Newsgroups: net.lang.c
Subject: Re: Functions that never return
Message-ID: <3347@watmath.UUCP>
Date: Wed, 24-Sep-86 10:55:45 EDT
Article-I.D.: watmath.3347
Posted: Wed Sep 24 10:55:45 1986
Date-Received: Fri, 26-Sep-86 20:51:36 EDT
References: <3274@watmath.UUCP> <86900064@haddock>
Organization: U of Waterloo, Ontario
Lines: 22

> >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.

Exactly where would you put this "void exit(int) {for (;;);}" ?
I imagine you mean putting it in the lint library, but if that is
the case, lint won't see it until the second pass.  It is the first
pass that needs to know that exit() doesn't return, just as it is
there that it needs to know what type it returns, and so this
information must be provided in the header file (or wherever) that
declares exit() as being of type (void).

At the moment, the header file contains at most "extern void exit(int);",
and there is nothing in that statement that indicates that the function
does not return.  To convey this information you must change the language
in some way, either by creating a new type (e.g. (goto)) or by creating
a new lint directive (e.g. /*GOTO*/).  Adding the lint directive is
easier to do; while adding the new type enables the compiler to generate
more efficient code.  The two different compilers we use here use those
two different approaches, and they are very useful for finding sections
of code that are never reached.