SoylentNews is people
SoylentNews
from the He's-checking-his-list,-he's-checking-it-twice... dept.
Unreal Engine continues to develop as new code is added and previously written code is changed. What is the inevitable consequence of ongoing development in a project? The emergence of new bugs in the code that a programmer wants to identify as early as possible. One of the ways to reduce the number of errors is the use of a static analyzer like PVS-Studio. Moreover, the analyzer is not only evolving, but also constantly learning to look for new error patterns, some of which we will discuss in this article. If you care about code quality, this article is for you.
[I debated running this story as it was specific to Unreal Engine and PVS-Studio. Stepping back and looking at the larger picture of static code analysis, there seems to be plenty of room for discussion. What, if any, static code analyzers have you used? How helpful were they? Was it effective in finding [obscure] bugs? How much time did running the analysis consume? Was it an automated part of your build process? How many false positives did you run into compared to actual bugs. On an entirely different perspective, is it easier to find coding errors in compiled code or interpreted? --martyb]
(Score: 3, Informative) by isj on Tuesday June 27 2017, @03:06AM (4 children)
I'm using Flexelint on a regular basis as well as Coverity. Both have their strengths and weaknesses. I also had a trail for PVS-studio an it was OK. The more tools the better.
Judging from an earlier discussion (https://soylentnews.org/article.pl?sid=17/05/10/0357233) it seems to me that that few developers know of static analysis.
With regard to specific tools:
GCC: getting better, but doesn't warn about unsavoury constructs that may be fine in kernel code but very dubious in user-land code. Warning suppressions is poor when compared to some of the other tools.
Flexelint: quite a lot of setup and false positive, but its laser-precision suppression rocks. And it warns about constructs that are technically OK, but dubious. And it can be adapted to some of the weird language extensions offered by embedded compilers.
Coverity: good value-tracking. Suppression is on a case-by-case basis and can get tedious.
PVS-studio: not bad. Found 64-bit errors that the other tools didn't. Didn't find errors the other tools did.
Conclusion: more tools are better.
With regard to compiled versus interpreted: Doesn't matter. It seems to me that what matters is statically typed versus dynamically typed. Statically typed languages are easier for static analysers to handle.
(Score: 2) by driverless on Wednesday June 28 2017, @10:45AM (3 children)
PVS Studio is nice, but has probably the second most annoying licensing model of any software analysis tool after BoundsChecker. Admittedly anything is second worst after BoundsChecker, whose licensing mechanism was designed by Satan to torment souls in Hell, but still...
Of the free tools, clang's analyzer is probably the best, and PREfast is the best if you go through and annotate all your code. Of the non-free ones I tend to prefer Coverity, although Fortify is also nice. It has far more FPs than Coverity, since Coverity makes elimination of FPs a major priority. Klockwork I would rate third, although it's not far behind Fortify.
One that I haven't tried is Goanna Studio, because they make it kinda painful to play with.
Oh: Downsides of Coverity, Fortify, and Klocwork is that you can't afford them unless you're a major corporation. PVS and Goanna are very expensive but affordable, the other three are out of reach for almost everyone except corps with deep pockets.
(Score: 2) by isj on Wednesday June 28 2017, @05:31PM (2 children)
It is interesting that you mention Fortify. I looked into it years ago but got the impression that the raw reports were being filtered for false positives by a group of merry Indians before you received the final report. Perhaps that was just for their semi-hosted solution.
(Score: 2) by driverless on Thursday June 29 2017, @03:17AM (1 child)
Fortify has many levels of reporting, so you can decide on how much detail you want. Which is basically deciding which level of FPs you're prepared to tolerate. The problem with it was, when I was looking at it, that to get a good level of detail you had to put up with huge numbers of FPs. Coverity at the time said they put... either 70 or 90%, can't remember which one it was, of their effort into dealing with FPs. That's what gave them the edge. Fortify just reported everything, and let you wind the level up and down.
(Score: 2) by isj on Thursday June 29 2017, @03:40PM
It sounds like the warning suppression possibilities in Forty is/were insufficient.
What I particularly like about Flexelint is that I can turn up the warning level (usually to 3) and then suppress warnings wholesale with high precision. For example, warning 1788 is "... local instance .. only used by its constructor and destructor" which normally indicates a forgotten and superfluous local variable. Except when it is deliberate. I can tell Flexelint about that with:
-esym(1788,boost::lock_guard)
and then all 1788 warnings about local instances of type boost::lock_guard goes away. And only that.