Trunk scan-build reports

Following the recent PVS Studio analysis of LLVM 8 (see I took a look at the current status of the scan-build CI against trunk: 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 blog article).

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 std::move does.
3 - use of uninitialized variables (or static analyzer thinks it is uninitialized).

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.......

Cheers, Simon.

Hey Simon,

This year we’ll be firing up a whole GSoC project to clean up these Static Analyzer false positives:

[1] [2]