FYI: clang static analyzer page has moved to http://scan.freebsd.your.org/freebsd-head/

[Roman Divacky]

On Wed, Jan 05, 2011 at 05:55:45PM +0100, Ulrich Sp??rlein wrote:
> On Wed, 05.01.2011 at 09:34:49 -0500, John Baldwin wrote:
> > On Wednesday, January 05, 2011 9:11:50 am Erik Cederstrand wrote:
> > > 
> > > Den 05/01/2011 kl. 14.56 skrev Erik Cederstrand:
> > > 
> > > > Ignoring contrib code for the moment, I decided to look at usr.sbin.pw
> > > > from 2011-01-05. There's one report (http://scan.freebsd.your.org/freebsd-head/usr.sbin.pw/2011-01-05-amd64/report-KkilQ3.html#EndPath)
> > > > which turns out to be a false positive:
> > > > 
> > > > * Step 6 calls cmdhelp() on line 168;
> > > > * cmdhelp() ends with "exit(EXIT_FAILURE);" on line 432 which I assume
> > > > is exit(3) from libc
> > > > * The analyzer doesn't know that this function never returns and
> > > > continues to flag a null dereference in step 8
> > > 
> > > The same is true of err(), verr(), errc(), verrc(), errx(), and verrx()
> > > which is also causing false positive reports. They ultimately call exit(3).
> > 
> > These are all marked as __dead2, so the compiler should "know" that these do
> > not return.
> 
> And clang did the right thing here in the past. Beware that it does no
> inter-procedural analysis yet, so it will usually miss that usage()
> calls exit unconditionally.
> 
> *But*, it should grok that for err(3) and exit(3). Now there are some
> possible remedies:
> 
> - get IPA to work with clang, or at least file a bug
> - mark functions as __dead2 (please don't do that)
> - come up with a way to mark the false positives (kinda impossible with
>   the way scan-build currently works)

The problem is that while exit() is __dead2 the actual cmdhelp() is not.
At least clang does not see it as such. Thus the static analyzer just
sees a call to a normal function (it does not recurse into it) and produces
this false positive...

I wonder how how hard would it to be to add some trivial IPA that analyzes
cases like this..