<html>

  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">

  </head>

  <body text="#000000" bgcolor="#FFFFFF">

    Hey Simon,<br>

    <br>

    This year we'll be firing up a whole GSoC project to clean up these

    Static Analyzer false positives:<br>

    <br>

    [1] <a class="moz-txt-link-freetext" href="http://llvm.org/OpenProjects.html#analyze-llvm">http://llvm.org/OpenProjects.html#analyze-llvm</a><br>

    [2] <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>

    <br>

    <blockquote type="cite">

      <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 

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

    </blockquote>

    <br>

  </body>

</html>