[cfe-dev] Coverity vs Clang Static analyzer

[Manuel Klimek]

+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
> GRR
>
>
>
> On Sun, Feb 23, 2014 at 4:16 AM, Manuel Klimek <klimek at google.com> wrote:
>
>> On Fri, Feb 21, 2014 at 8:16 AM, G Raghuram <contactraghu at gmail.com>wrote:
>>
>>> Hi All,
>>> 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.
>>>
>>> Manuel,
>>> We are using it for C++.
>>>
>>
>> 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).
>>
>> Cheers,
>> /Manuel
>>
>>
>>>
>>>
>>>
>>>
>>> On Thu, Feb 20, 2014 at 6:01 AM, miroslav.fontan <
>>> miroslav.fontan at wincor-nixdorf.cz> wrote:
>>>
>>>> Hi,
>>>>
>>>> We use Coverity, Clang, CPPCheck, PC-Lint. Each of these program reports
>>>> different errors, intersection is almost empty. Coverity can find the
>>>> most
>>>> "real" runtime problems, false positive rate depends on aggressity
>>>> level.
>>>>
>>>> For bugtracking we redirect all reports/outputs to the SonarQube
>>>>
>>>> Mira
>>>>
>>>> > -----Original Message-----
>>>> > From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu
>>>> ]
>>>> > On Behalf Of David Chisnall
>>>> > Sent: Thursday, February 20, 2014 9:43 AM
>>>> > To: G Raghuram
>>>> > Cc: Clang Dev
>>>> > Subject: Re: [cfe-dev] Coverity vs Clang Static analyzer
>>>> >
>>>> > Hi,
>>>> >
>>>> > On 20 Feb 2014, at 06:42, G Raghuram <contactraghu at gmail.com> wrote:
>>>> >
>>>> > > Can someone please comment on features of Clang static analyzer vs
>>>> > Coverity? Does coverity catch any extra errors or can we just do a
>>>> > drop-in replacement.?
>>>> >
>>>> > We use both for FreeBSD.  Coverity catches more things, but also has a
>>>> > somewhat higher false positive rate.  Currently, the most useful
>>>> > feature that Coverity has and the clang static analyser lacks is the
>>>> > ability to track bugs over source code changes.  Clang requires
>>>> > annotations to be placed in the source code to silence warnings.  This
>>>> > is fine for our code, but a pain for third-party code where we don't
>>>> > want to increase the effort for merging.  Coverity lets you flag a bug
>>>> > as a false positive.  This is also nicer from a review perspective -
>>>> it
>>>> > lets you investigate the bugs other people have marked as false
>>>> > positives and check that they really were.
>>>> >
>>>> > The other difference is momentum.  The clang analyser is under very
>>>> > active development and it catches a lot more things than it did a year
>>>> > ago.  It's also much easier to write plugins for if you want to check
>>>> > for correct usage of your own APIs or idioms.
>>>> >
>>>> > David
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > cfe-dev mailing list
>>>> > cfe-dev at cs.uiuc.edu
>>>> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>>
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140224/24afdb80/attachment.html>