<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;"><br><div><div>On Nov 15, 2013, at 9:28 AM, Manuel Klimek <<a href="mailto:klimek@google.com">klimek@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">On Fri, Nov 15, 2013 at 6:25 PM, Jordan Rose <span dir="ltr"><<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<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; position: static; z-index: auto;"><div style="word-wrap:break-word"><br><div><div class="im"><div>On Nov 15, 2013, at 3:24 , Manuel Klimek <<a href="mailto:klimek@google.com" target="_blank">klimek@google.com</a>> wrote:</div>
<br><blockquote type="cite"><blockquote class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
While I’m always happy when the analyzer gets more use, the text mode is something we haven’t ever really supported or worked on productizing—it’s always been a lo-fi output format that’s not guaranteed for anything besides debugging. Shipping a tool that reports paths in text mode is a big step, and there could easily be QoI issues we haven’t had to care about until now. (Also, sometimes paths are dozens of notes long.)<br>
</blockquote><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
I'm not too concerned about this - we had Pavel running the static analyzer on all our code, outputting to text format, and analyzing the results, and I don't remember the text format ever being an issue. I don't really have a good idea what other format we'd want to use - our main use case is overlaying the warnings in various steps of our workflow.</div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
If we run into problems with the static analyzer's text output, and you say it's not mean to be "production ready", would that mean you wouldn't want to accept patches to make it production ready? :)</div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
</div></blockquote><div><br></div></div><div>Patches to make the text output better are certainly fine. We’ve just never put effort into it up until now—for a while the notes weren’t even associated with the right warnings—and we’d need to make sure we don’t optimize the textual notes at the cost of the HTML output. OTOH, the HTML output could also use some love.</div>
<div><br></div><div>Ted, Anna, do you have an opinion here?</div></div></div></blockquote></div></div></div></blockquote><div><br></div>Basically, the most comprehensive output you get for the static analyzer is the plist format (used by Xcode), followed by HTML, and finally by text. You don't get the best user experience by looking at text output. We are definitely open to patches that would improve text format, thought it will always be inferior to other formats and visualizations. If consuming plist format is an option in your use case, I'd recommend going for that instead.</div><div><br></div><div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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; position: static; z-index: auto;"><div style="word-wrap:break-word"><div><div><br></div><br><blockquote type="cite"><div class="im"><blockquote class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Additionally, the analyzer is not expected to do sensible things without the “core" checkers enabled if you’re running any path-sensitive checks. At some point I’ll fix things so that that’s automatic, but for now please always include “core” in the control list.<br>
</blockquote><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
What would be a good test case for a path sensitive check that relies on core?</div></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
I implemented your suggestion in r194807, but didn't find a good way to test…</div></blockquote><br></div><div>Null pointer dereferences, null function calls, and use of undefined values are checked by core, as well as the fact that noreturn functions are actually noreturn. That last is fairly important to get any kind of useful results on code that uses asserts.</div>
</div></blockquote><div><br></div><div>What I was trying to ask is: what would be a good test of a checker which is not in core that will misbehave if core is not enabled?</div><div><br></div></div></div></div></blockquote><div><br></div><div>This is one such example:</div><div><div>#include <stdlib.h></div><div>int test(int *valid) {</div><div> int *p = malloc(4);</div><div> int x = 1;</div><div> if (x)</div><div> exit(0);</div><div> else </div><div> free(p); </div><div> return 0;</div><div>}</div><div><br></div><div>This would report a leak if <span style="font-family: Menlo; font-size: 11px;">unix.Malloc </span>checker is on but core is not on. (core tells us that the execution does not continue after a call to exit(0).)</div></div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Cheers,</div><div>/Manuel</div>
</div></div></div>
</blockquote></div><br></body></html>