Path: utzoo!utgpu!watmath!rbutterworth
From: rbutterworth@watmath.waterloo.edu (Ray Butterworth)
Newsgroups: comp.lang.c
Subject: Re: YALF (yet another lint foulup)
Message-ID: <22751@watmath.waterloo.edu>
Date: 15 Dec 88 21:07:44 GMT
References: <4700030@m.cs.uiuc.edu> <6720@june.cs.washington.edu>
Organization: U of Waterloo, Ontario
Lines: 48

In article <6720@june.cs.washington.edu>, kolding@june.cs.washington.edu (Eric Koldinger) writes:
> Bill Smith writes:
> >Lint believes this simple program has both return(e); and just return;
> >function()
> >{
> >   int flag;
> >   do{
> >       return(3);
> >   } while(flag);
> >}
> And so it does....
> Lint can't determine where it will drop out, it only determines if there
> is a path that could be executed to get there.

Not true.  Replace the "return(3)" with a "goto label" and put a label
in front of the do statement.  You'll get the same messages from lint.
Lint knows what a goto does since it is part of the language.
It also knows what a return does since it too is part of the language.
Had it been written "return 3;" instead of like a function "return(3);"
this would have been more obvious.  Some versions of lint do know about
functions that don't return (declared as "extern /*GOTO*/ abort();"),
but most don't.

In any case, lint should have produced two warnings, not only the one
that was wrong:
  xx.c(10): warning: statement not reached
  xx.c(11): warning: function "func" has return(e); and return;

The first was correct, since the "while" part is never executed.
But after issuing a "not reached" warning, lint resets its flag
that indicates that the code has not been reached, and thus it
thinks the next line really is reached and gives the second warning.

It has to be this way, otherwise something like:
  goto label;
  a = 1;
  b = 2;
  ...
  z = 26;
would cause 26 "statement not reached" messages.
After complaining that "a = 1;" is not reached, you really don't
want to see the other 25 messages.

Consider it like getting 200 lines of compiler errors.
Only the first few probably make any sense.
The rest are either caused by the first mistakes, or are caused
by the compiler's attempts to recover after those mistakes.