<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<body text="#000000" bgcolor="#FFFFFF">
This year we'll be firing up a whole GSoC project to clean up these
Static Analyzer false positives:<br>
 <a class="moz-txt-link-freetext" href="http://llvm.org/OpenProjects.html#analyze-llvm">http://llvm.org/OpenProjects.html#analyze-llvm</a><br>
 <a class="moz-txt-link-freetext" href="http://lists.llvm.org/pipermail/cfe-dev/2019-April/061971.html">http://lists.llvm.org/pipermail/cfe-dev/2019-April/061971.html</a><br>
<pre>Following the recent PVS Studio analysis of LLVM 8 (see
<a href="https://bugs.llvm.org/show_bug.cgi?id=41655">https://bugs.llvm.org/show_bug.cgi?id=41655</a>) I took a look at the
current status of the scan-build CI against trunk:
<a href="https://llvm.org/reports/scan-build/">https://llvm.org/reports/scan-build/</a> to see how many of these we should
already have known about.
As of the build on Sunday May 5 (svn359972) we have 935 bugs in the
report (with only a vague overlap with the issues mentioned in the PVS
Studio article but they are quite selective on the bugs they put in the
Looking through the scan-build report's links, I can understand why we
may not have been vigilant at investigating many of these - a lot appear
to be false positives, but to be honest many are trivial to avoid
(better initialization, assertions etc.). I've committed a few NFCs that
cleanup things here and there, but it'd be better to get code owners and
people invested in particular areas of the code to take a look and
decide if they are worth a NFC tweak; show an actual issue (in the code
or static analyzer itself); or can just be ignored (possibly add a
comment to the code to note the warning?).
Refactoring code just to appease a static analysis isn't often a good
policy, but I do think we should be doing more to improve things here.
Particular areas of concern:
1 - the inevitable nullptr/dereference warnings - there always seems to
be a particular (weird? impossible?) logic path that allows these cases
- we have so many of these that separating the real bugs from the
impossible cases is a major undertaking.
2 - bad use of std::move - use of the variable after it has been moved
is particularly common and suggests a lack of understanding of what
3 - use of uninitialized variables (or static analyzer thinks it is
I'd really like to get some idea of how much an issue the community
think this is or whether I'm just tilting at windmills.......