<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">Am 29.04.20 um 23:11 schrieb Mandeep
      Singh Grang:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAPzOYCjTdz_q0O-tCwyUcqHLcvGArj47d9FPv_eoc=SWNap=9Q@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_default">My previous email details why we are
          doing this: <a
            href="http://lists.llvm.org/pipermail/llvm-dev/2020-April/141167.html"
            moz-do-not-send="true">http://lists.llvm.org/pipermail/llvm-dev/2020-April/141167.html</a></div>
        <div class="gmail_default">Basically, we ran the PREfast static
          analysis tool on LLVM/Clang and it reported a lot of warnings.
          I guess some of them are false positives after all.</div>
      </div>
    </blockquote>
    Thanks for the link. There is nothing wrong with running additional
    tools on LLVM.<br>
    <blockquote type="cite"
cite="mid:CAPzOYCjTdz_q0O-tCwyUcqHLcvGArj47d9FPv_eoc=SWNap=9Q@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_default">As David suggests that maybe I should
          validate these warnings by also running the clang static
          analyzer.</div>
      </div>
    </blockquote>
    You could have a look at <a class="moz-txt-link-freetext" href="http://llvm.org/reports/scan-build/">http://llvm.org/reports/scan-build/</a>. It's
    not terribly up-to-date though, so you might also run it yourself.<br>
    <blockquote type="cite"
cite="mid:CAPzOYCjTdz_q0O-tCwyUcqHLcvGArj47d9FPv_eoc=SWNap=9Q@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_default"> There are a lot of other warnings
          reported by the tool. Here is the full list: <a
href="https://docs.google.com/spreadsheets/d/1h_3tHxsgBampxb7PXoB5lgwiBSpTty9RLe5maIQxnTk/edit?usp=sharing"
            moz-do-not-send="true">https://docs.google.com/spreadsheets/d/1h_3tHxsgBampxb7PXoB5lgwiBSpTty9RLe5maIQxnTk/edit?usp=sharing</a>.</div>
      </div>
    </blockquote>
    <p>In my opinion you're probably not losing a lot by filtering out
      the types of issues that the Clang static analyzer can find as
      well. So for example, ignore the null dereferences since Clang has
      essentially the same check. Of course it could be that the tool
      finds additional issues, I can't really say that. But you can see
      in the report that there quite a few issues of a similar kind.
      (This one isn't among them, however.)<br>
    </p>
    <p>For analyzing the issues in the list, it would be good to note
      the git commit of your analysis run, otherwise it might be hard to
      follow the reports.<br>
    </p>
    <blockquote type="cite"
cite="mid:CAPzOYCjTdz_q0O-tCwyUcqHLcvGArj47d9FPv_eoc=SWNap=9Q@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_default">If the community is interested in
          getting those fixed I can upstream patches.</div>
      </div>
    </blockquote>
    <p>Improvements are always welcome, but unfortunately no static
      analysis tool only reports actual issues. Otherwise one could hope
      that the Clang findings would have been all fixed by now.</p>
    <p>So I think you need to carefully inspect the reports. It's not a
      bad idea to start with a random sample of the issues reported by
      every check. Avoid stylistic issues like shadowing: people have
      different opinions on that. Then try to find out if there is a
      real issue, or if you can think of a way to improve the code.
      (That's often subjective, of course. But if you can rewrite code a
      bit to make it more obvious that a certain bad thing can't happen,
      you'll find open ears.)</p>
    <p>The best thing is of course if you can use the report to
      construct failing test cases, but I wouldn't put the bar that
      high.<br>
    </p>
    <p>Best regards,<br>
      Aaron<br>
    </p>
  </body>
</html>