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? > > > 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? Cheers, /Manuel
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
