<div class="gmail_quote">On Fri, May 13, 2011 at 12:24 AM, Erik Cederstrand <span dir="ltr"><<a href="mailto:erik@cederstrand.dk">erik@cederstrand.dk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi Ted,<br>
<br>
Den 12/05/2011 kl. 22.08 skrev Ted Kremenek:<br>
<div class="im"><br>
> On May 12, 2011, at 11:19 AM, John Smith wrote:<br>
><br>
>> But my main point wasnt really finding bugs in the projects<br>
>> themselves, but finding & fixing bugs in the analyzer (by decreasing<br>
>> the potential for false positives).<br>
><br>
> Thanks John.  That's what I am hopeful for as well.<br>
><br>
> 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.<br>

<br>
</div>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.<br>

<br>
I created a bug report some time ago <a href="http://llvm.org/bugs/show_bug.cgi?id=8914" target="_blank">http://llvm.org/bugs/show_bug.cgi?id=8914</a> I realize that fixing this is non-trivial, but it would be nice if the analyzer could at least handle the following:<br>

<br>
if foo():<br>
        x = 5<br>
else:<br>
        exit()<br>
bar(x)<br>
<br>
without complaining that x might be uninitialized.<br></blockquote><div><br>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.:<br>
<br>  void fatal() {<br>    exit(-1);<br>  }<br><br>  if foo() x = 5;<br>  else fatal();<br>  bar(x);<br><br>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.<br>
<br></div></div>Just my $0.02 ;)<br><br>Cheers,<br>Kaelyn<br>