+alexfh who is going to spend time on this
On Fri, Nov 15, 2013 at 7:59 PM, Anna Zaks <[email protected]> wrote: > > On Nov 15, 2013, at 9:28 AM, Manuel Klimek <[email protected]> wrote: > > On Fri, Nov 15, 2013 at 6:25 PM, Jordan Rose <[email protected]>wrote: > >> >> On Nov 15, 2013, at 3:24 , Manuel Klimek <[email protected]> wrote: >> >> 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.) >>> >> >> 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. >> >> 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? :) >> >> >> 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. >> >> Ted, Anna, do you have an opinion here? >> > > 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. > > > >> >> 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. >>> >> >> What would be a good test case for a path sensitive check that relies on >> core? >> I implemented your suggestion in r194807, but didn't find a good way to >> test… >> >> >> 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. >> > > 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? > > > This is one such example: > #include <stdlib.h> > int test(int *valid) { > int *p = malloc(4); > int x = 1; > if (x) > exit(0); > else > free(p); > return 0; > } > > This would report a leak if unix.Malloc checker is on but core is not on. > (core tells us that the execution does not continue after a call to > exit(0).) > > Cheers, > /Manuel > > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
