<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 5, 2016, at 12:59 PM, Craig, Ben <<a href="mailto:ben.craig@codeaurora.org" class="">ben.craig@codeaurora.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
  
    <meta content="text/html; charset=windows-1252" http-equiv="Content-Type" class="">
  
  <div bgcolor="#FFFFFF" text="#000000" class="">
    On 2/5/2016 1:52 PM, Anna Zaks wrote:<br class="">
    <blockquote cite="mid:3444E61C-5E89-43F9-8048-E197C7CD4CEB@apple.com" type="cite" class="">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252" class="">
      <br class="">
      <div class="">
        <blockquote type="cite" class="">
          <div class="">On Feb 5, 2016, at 6:15 AM, Craig, Ben <<a moz-do-not-send="true" href="mailto:ben.craig@codeaurora.org" class=""></a><a class="moz-txt-link-abbreviated" href="mailto:ben.craig@codeaurora.org">ben.craig@codeaurora.org</a>>
            wrote:</div>
          <br class="Apple-interchange-newline">
          <div class="">
            <meta content="text/html; charset=windows-1252" http-equiv="Content-Type" class="">
            <div bgcolor="#FFFFFF" text="#000000" class=""> On 2/4/2016
              5:52 PM, <Alexander G. Riccio> wrote:<br class="">
              <blockquote cite="mid:CAN3N+zmnjVq+bjBwCexZmpcnVxnQv1m-O75B+o09P53yv5Xh_g@mail.gmail.com" type="cite" class="">
                <div dir="ltr" class="">
                  <blockquote class="gmail_quote" style="margin:0px 0px
                    0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8px" class="">Consider making
                      "no </span><span style="font-size:12.8px" class="">detailed
                      analysis" an option for -enable-analyze-</span><span style="font-size:12.8px" class="">pass</span><span style="font-size:12.8px" class=""> to help with
                      these </span><span style="font-size:12.8px" class="">use cases</span><br class="">
                  </blockquote>
                  <div class=""><br class="">
                  </div>
                  <div class="">Eh? Do you mean less detailed output or
                    less detailed analysis done by clang?<br class="">
                  </div>
                </div>
              </blockquote>
              I mean analysis that just emits diagnostics on the
              console, but doesn't emit a .plist or .html report.<br class="">
            </div>
          </div>
        </blockquote>
        <br class="">
        <div class="">How user-friendly is the text output? Had anyone analyzed a
          large codebase, triaged the results, and fixed the reported
          bugs with just relying on the text output? </div>
      </div>
      <br class="">
    </blockquote>
    <br class="">
    If you have a large, "dirty" code base, then the test output on its
    own isn't going to be terribly useful.<br class="">
    <br class="">
    However, you can get useful information from the text output if you
    start with a code base that already runs cleanly through the static
    analyzer.  The warning is likely pointing at some code that you just
    modified.  An example from one of the tests...<br class="">
    <br class="">
      long *lp1 = malloc(sizeof(short)); // expected-warning {{Result of
    'malloc' is converted to a pointer of type 'long', which is
    incompatible with sizeof operand type 'short'}}<br class="">
    <br class=""></div></div></blockquote><div><br class=""></div>This is not a path-sensitive check whereas most of the analyzer checks are path-sensitive. It might be hard for people to understand the warnings by just looking at the text output, which has mainly been designed for lit testing. This is also a problem with advertising 'clang —analyzer' to the end users, who are not likely to implement their own plist viewers. Scan-build is a much better “batteries included” option.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div bgcolor="#FFFFFF" text="#000000" class="">
    That warning text on the command line is useful by itself,
    especially if it is fresh code.<br class="">
    <br class="">
    Some checkers may produce less useful output.  That's fine, and I
    can understand why we may not want to make stdout-only the default
    as a result.  I do think it's useful as an option though.<br class="">
    <br class="">
    <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>
  </div>

</div></blockquote></div><br class=""></body></html>