Path: utzoo!utgpu!watmath!clyde!att!mtuxo!rolls!westmark!mole-end!mat
From: mat@mole-end.UUCP (Mark A Terribile)
Newsgroups: comp.lang.c
Subject: Re: YALF (yet another lint foulup)
Summary: Oh yes LINT SHOULD know ...
Message-ID: <122@mole-end.UUCP>
Date: 17 Dec 88 18:28:53 GMT
References: <4700030@m.cs.uiuc.edu> <717@auspex.UUCP>
Organization: mole-end--private system.  admin: mole-end!newtnews
Lines: 34

For the code fragment:

	. . .
	do
	{
		return 1 ;
	} while( 0 )
}
> "lint" has no way of knowing, given its somewhat unsophisticated
> analysis, that the loop never terminates; ...
> function *would* have something that amounts to just a "return;".
...
> ... there is actually a "lint" feature to be used in this case:
> 
> 	/*NOTREACHED*/

I believe that /*NOTREACHED*/ is for things like exit(), which cannot return
at all.  Given that LINT professes to know about variables used before set,
it is certainly LINT's business to do a little basic flow analysis.  It
would be nice if LINT would warn that this ``loop'' does not and can not loop.

The parsing and data type analysis that LINT actually must do is much
hairier than the linked-list games that you play to find out what is and
isn't reached.  Moreover, it would help LINT to get the used/set checks
right.

With ANSI C and function prototypes, we may hope that LINT goes away.  We
now understand better what sort of checks to apply (Bjarne Stroustrup's C++
processors do a much better job than LINT, and without the extraneous noise)
and it makes sense to put them in the compiler.
-- 

(This man's opinions are his own.)
From mole-end				Mark Terribile