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

[Ulrich Spörlein]

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)

All interested parties with src access are encouraged to take a look at
our Coverity Prevent installation (which is down for maintenance, but
should be up soon).

Regards,
Uli