<div dir="ltr">+Alex McCarthy, who has recently started to invest some cycles<div>+Daniel Connelly, who has done the stats with the current static analyzer for chromium</div><div>+Ted & Jordan, to correct me when I say something wrong ;)</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">(for the @google people cc'ed, please note this is a reply on a public mailing list)<br><br><div class="gmail_quote">On Mon, Feb 24, 2014 at 5:57 AM, G Raghuram <span dir="ltr"><<a href="mailto:contactraghu@gmail.com" target="_blank">contactraghu@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><div>Manuel,<br></div>Thanks for the information. I would love to be able to help... Do let me know some bugs I should start looking at.<br>
<br></div><div>50% false positives implies there is lots of scope for improvement. Our code base is mostly C++ with liberal usage of templates and C++11 features.<br></div></div></div></blockquote><div><br></div><div>Actually, pretty much all of them come from one pattern (on our code bases):</div>
<div>We have CHECK macros that create temporary objects that have noreturn destructors (they die with a nice stack trace). We use them pretty extensively throughout our code base.</div><div>To correctly model this, we need tracking of lifetime of temporaries. The most current bug that also includes references to the rest of the enchilada is here:</div>
<div><a href="http://llvm.org/bugs/show_bug.cgi?id=15599">http://llvm.org/bugs/show_bug.cgi?id=15599</a><br></div><div><br></div><div>Cheers,</div><div>/Manuel</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div><div>
<br></div>Thanks<br></div>GRR<div><div class="h5"><br><div class="gmail_extra">
<br><br><div class="gmail_quote">On Sun, Feb 23, 2014 at 4:16 AM, Manuel Klimek <span dir="ltr"><<a href="mailto:klimek@google.com" target="_blank">klimek@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>On Fri, Feb 21, 2014 at 8:16 AM, G Raghuram <span dir="ltr"><<a href="mailto:contactraghu@gmail.com" target="_blank">contactraghu@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div>Hi All,<br>Thank you for your responses. I get a feeling that clang can do a lot of things that Coverity does, so switching to it may not be a problem.<br>
<br></div>Manuel,<br></div>We are using it for C++.<br></div></blockquote><div><br></div></div><div>I'd say C++ is still the weak part of the analyzer (your milage might vary depending on how "C++" your code base actually is). We currently get > 50% false positives (on the Chromium code base). If you're interested in helping with a solution, I can point you at the bugs to start (we've found mainly one hairy bug that's left over - correct tracking of destructors of temporaries).</div>
<div><br></div><div>Cheers,</div><div>/Manuel</div><div><div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">
<br><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div>On Thu, Feb 20, 2014 at 6:01 AM, miroslav.fontan <span dir="ltr"><<a href="mailto:miroslav.fontan@wincor-nixdorf.cz" target="_blank">miroslav.fontan@wincor-nixdorf.cz</a>></span> wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>Hi,<br>
<br>
We use Coverity, Clang, CPPCheck, PC-Lint. Each of these program reports<br>
different errors, intersection is almost empty. Coverity can find the most<br>
"real" runtime problems, false positive rate depends on aggressity level.<br>
<br>
For bugtracking we redirect all reports/outputs to the SonarQube<br>
<br>
Mira<br>
</div><div><div><div><br>
> -----Original Message-----<br>
> From: <a href="mailto:cfe-dev-bounces@cs.uiuc.edu" target="_blank">cfe-dev-bounces@cs.uiuc.edu</a> [mailto:<a href="mailto:cfe-dev-bounces@cs.uiuc.edu" target="_blank">cfe-dev-bounces@cs.uiuc.edu</a>]<br>
> On Behalf Of David Chisnall<br>
> Sent: Thursday, February 20, 2014 9:43 AM<br>
> To: G Raghuram<br>
> Cc: Clang Dev<br>
> Subject: Re: [cfe-dev] Coverity vs Clang Static analyzer<br>
><br></div><div><div>
> Hi,<br>
><br>
> On 20 Feb 2014, at 06:42, G Raghuram <<a href="mailto:contactraghu@gmail.com" target="_blank">contactraghu@gmail.com</a>> wrote:<br>
><br>
> > Can someone please comment on features of Clang static analyzer vs<br>
> Coverity? Does coverity catch any extra errors or can we just do a<br>
> drop-in replacement.?<br>
><br>
> We use both for FreeBSD. Coverity catches more things, but also has a<br>
> somewhat higher false positive rate. Currently, the most useful<br>
> feature that Coverity has and the clang static analyser lacks is the<br>
> ability to track bugs over source code changes. Clang requires<br>
> annotations to be placed in the source code to silence warnings. This<br>
> is fine for our code, but a pain for third-party code where we don't<br>
> want to increase the effort for merging. Coverity lets you flag a bug<br>
> as a false positive. This is also nicer from a review perspective - it<br>
> lets you investigate the bugs other people have marked as false<br>
> positives and check that they really were.<br>
><br>
> The other difference is momentum. The clang analyser is under very<br>
> active development and it catches a lot more things than it did a year<br>
> ago. It's also much easier to write plugins for if you want to check<br>
> for correct usage of your own APIs or idioms.<br>
><br>
> David<br>
><br>
><br>
</div></div></div></div><div><div><div><div>> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br>
<br>
</div></div></div></div></blockquote></div><br></div></div>
</blockquote></div></div></div><br></div></div>
</blockquote></div><br></div></div></div></div>
</blockquote></div><br></div></div>