<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    I like static analysis, but I do not think the static analysis
    available in clang today for null checking is suitable for -Wall. 
    One of the reasons is because it is difficult to silence false
    positives (as you mentioned).  More importantly though, the impact
    to build time is quite substantial.  Nullability checks are path
    sensitive, and path sensitive checks are super-exponential.  If a
    file takes seconds to compile, it is fairly common for it to take
    minutes to analyze.<br>
    <br>
    I'm fine with the check being under a different flag, but lumping it
    in with -Wall would cause a lot of developer pain.  In fact, I would
    very much like to be able to run the analyzer at the same time that
    I do a compile.  That idea has been discussed before though, and
    there was resistance:<br>
    <a class="moz-txt-link-freetext" href="http://lists.llvm.org/pipermail/cfe-dev/2013-July/031097.html">http://lists.llvm.org/pipermail/cfe-dev/2013-July/031097.html</a><br>
    <br>
    For item 3., I was under the impression that most smart pointer
    classes inlined well enough that the static analyzer was still
    effective at finding null issues.  Do you have a small example that
    causes a null pointer warning with a raw pointer, but doesn't cause
    a null pointer warning with a smart pointer?<br>
    <br>
    2. and 4. seem like reasonable ideas to me, assuming they are
    implementable.<br>
    <br>
    <div class="moz-cite-prefix">On 11/6/2015 3:31 PM, George Burgess IV
      via cfe-dev wrote:<br>
    </div>
    <blockquote
cite="mid:CAKh6zBE9ezKWhHBnK44qOpiT2Hdv45i9w0JM19gmphf24LZ4UA@mail.gmail.com"
      type="cite">
      <div dir="ltr">Hello friends!
        <div><br>
        </div>
        <div>I've been evaluating the state of null analysis/etc. in
          clang recently, and it looks like clang's story for static
          nullness analysis has been getting quite a bit better over
          time. With the help of others, I've identified a few areas
          where we may be able to improve, but I'd really like opinions
          on whether we think these changes would actually be a good
          thing.</div>
        <div><br>
        </div>
        <div>Specifically, I have four distinct changes in mind:</div>
        <div>1. Turn some amount of nullability analysis on by default
          (with -Wall) in clang. This would be conceptually <i>very</i> similar
          to uninitialized value checking, and would be able to catch
          simple cases like</div>
        <div><br>
        </div>
        <div>Foo *p = nullptr;</div>
        <div>if (p = getPtr())</div>
        <div>  p->oneThing();</div>
        <div>else</div>
        <div>  p->anotherThing(); // warning: p is null.</div>
        <div><br>
        </div>
        <div>...But no promises for any nontrivial cases (without
          heavily annotated locals/function signatures ;) ), because
          there's currently no planned way to silence the warning if
          we're somehow wrong.</div>
        <div><br>
        </div>
        <div>2. Speaking of nullness annotations, clang supports a lot
          of them. Migrating old code to use them could be painful, so
          having a <a moz-do-not-send="true"
href="https://docs.google.com/document/d/1vXuhRTQsbf4F9PbFtCoapuAhCU4RrD-IAiaUfTwp4uA/edit?usp=sharing"
            target="_blank">tool that annotates obvious things for us
            may be nice to have</a> (<a moz-do-not-send="true"
href="https://docs.google.com/document/d/1vXuhRTQsbf4F9PbFtCoapuAhCU4RrD-IAiaUfTwp4uA/edit?usp=sharing"
            target="_blank">https://docs.google.com/document/d/1vXuhRTQsbf4F9PbFtCoapuAhCU4RrD-IAiaUfTwp4uA/edit?usp=sharing</a>).</div>
        <div><br>
        </div>
        <div>3. Add a CXXRecordDecl-level attribute that instructs
          nullness analysis to treat instances of the attributed type as
          a pointer for the sake of nullness analysis. This would enable
          nullness analysis of things like unique_ptr/shared_ptr/...
          Doc is available <a moz-do-not-send="true"
href="https://docs.google.com/document/d/1Zyb8o210EqkAXxrnrv4XtRu4w_i0yXO04p4KTuTde4M/edit?usp=sharing"
            target="_blank">here</a> (<a moz-do-not-send="true"
href="https://docs.google.com/document/d/1Zyb8o210EqkAXxrnrv4XtRu4w_i0yXO04p4KTuTde4M/edit?usp=sharing"
            target="_blank">https://docs.google.com/document/d/1Zyb8o210EqkAXxrnrv4XtRu4w_i0yXO04p4KTuTde4M/edit?usp=sharing</a>).</div>
        <div><br>
        </div>
        <div>4. Add clang_tidy checks for missing nullness annotations
          on function signatures/global variable decls/member variable
          decls/...</div>
        <div><br>
        </div>
        <div>Like said, any feedback on how {useful,useless} we think
          these things would be (and feedback on on the designs
          themselves) is highly appreciated. :)</div>
        <div><br>
        </div>
        <div>Thanks for your time!</div>
        <div>George</div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
cfe-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a>
</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
</pre>
  </body>
</html>