[cfe-dev] Clang Analysis of several open source projects.

[Kaelyn Uhrain]

On Fri, May 13, 2011 at 12:24 AM, Erik Cederstrand <erik at cederstrand.dk>wrote:

> Hi Ted,
>
> Den 12/05/2011 kl. 22.08 skrev Ted Kremenek:
>
> > On May 12, 2011, at 11:19 AM, John Smith wrote:
> >
> >> But my main point wasnt really finding bugs in the projects
> >> themselves, but finding & fixing bugs in the analyzer (by decreasing
> >> the potential for false positives).
> >
> > Thanks John.  That's what I am hopeful for as well.
> >
> > To make this exercise the most constructive, we need actual bug reports
> against the analyzer.  Diagnosing a sea of reports, and complaining that
> there are too many false positives just really isn't constructive or helpful
> on its own.
>
> FreeBSD is continually running the analyzer on our code, which has already
> uncovered a lot of bugs. I have previously sifted through a lot of the bug
> reports, and a very large part of the false positives fall in the category
> of the analyzer not detecting that a function never returns, i.e. the IPA
> not being smart enough.
>
> I created a bug report some time ago
> http://llvm.org/bugs/show_bug.cgi?id=8914 I realize that fixing this is
> non-trivial, but it would be nice if the analyzer could at least handle the
> following:
>
> if foo():
>        x = 5
> else:
>        exit()
> bar(x)
>
> without complaining that x might be uninitialized.
>

I just noticed that same false positive on a small piece of code I have.  In
my case though, the location of the complaint wasn't where exit() was called
but where a function wrapping exit() was called, e.g.:

  void fatal() {
    exit(-1);
  }

  if foo() x = 5;
  else fatal();
  bar(x);

Once I added the declaration "void fatal() __attribute__ ((noreturn));",
clang's static analyzer no longer complained that x might be uninitialized.
I haven't looked into the code, but I suspect that either the analyzer isn't
propagating the noreturn function attribute properly (in cases where the
only return path in a function hits a call to another function marked as
noreturn) or possibly that the attribute is missing in a key spot within a
header.

Just my $0.02 ;)

Cheers,
Kaelyn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110513/943e75f0/attachment.html>