Synopsys has decided to acquire. We are a direct competitor of Synopsys and have been using coverity. As I work for a direct competitor, I believe from now on, we will have to decrease our dependence on Coverity.
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.?
Synopsys has decided to acquire. We are a direct competitor of Synopsys
and have been using coverity. As I work for a direct competitor, I believe
from now on, we will have to decrease our dependence on Coverity.
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
Which language are you interested in? (C, Obj-C or C++)?
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
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.
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
+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
FYI, I am running once a day scan-build on llvm toolchain (llvm + clang
+ lldb + compiler-rt + polly) base code: http://buildd-clang.debian.net/scan-build/
If you want to see on a real base code the advantages / drawbacks.
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.)