[cfe-dev] Coverity vs Clang Static analyzer

[Jordan Rose]

On Feb 24, 2014, at 1:04 , Manuel Klimek <klimek at google.com> wrote:

> +Alex McCarthy, who has recently started to invest some cycles
> +Daniel Connelly, who has done the stats with the current static analyzer for chromium
> +Ted & Jordan, to correct me when I say something wrong ;)
> 
> (for the @google people cc'ed, please note this is a reply on a public mailing list)
> 
> On Mon, Feb 24, 2014 at 5:57 AM, G Raghuram <contactraghu at gmail.com> wrote:
> Manuel,
> Thanks for the information. I would love to be able to help... Do let me know some bugs I should start looking at.
> 
> 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.
> 
> Actually, pretty much all of them come from one pattern (on our code bases):
> 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.
> 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:
> http://llvm.org/bugs/show_bug.cgi?id=15599
> 
> Cheers,
> /Manuel
> 

Thanks for roping us in. C++ codebases are indeed still fairly unpredictable for the analyzer: on some it will do just fine, on some it will have a few false positives, and on some (like Chromium) it pretty much fails to understand the intent of the code. Manuel has pointed to the largest issue on the table, but there are probably easier places to get started. Syvestre's right that the Bugzilla database isn't a bad place to start; for a discussion of analyzer internals, I recommend the talk linked from our Checker Developer Manual page.

On a higher-level note, a big difference between Coverity's tools and our analyzer is that ours (currently) only looks at one translation unit at a time. This means that Coverity's tool will find some interprocedural bugs that ours cannot. This is something we'd like to improve in the long run, but it would be a big new effort, not an obvious extension to what's already there, and we'd want to make sure it was still performant.

People have also noted Coverity's integrated issue tracking; our support for this is rudimentary at best. The most common way to silence false positives with our analyzer is to use assertions.

(I appreciated seeing everyone's feedback, and am glad to see our tool is still useful even when up against commercial offerings.)

Jordan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140224/ccc0b8e0/attachment.html>