[cfe-dev] Idea for better invoking static analysis via command line

Anna Zaks via cfe-dev cfe-dev at lists.llvm.org
Fri Feb 5 15:29:55 PST 2016


> On Feb 5, 2016, at 12:59 PM, Craig, Ben <ben.craig at codeaurora.org> wrote:
> 
> On 2/5/2016 1:52 PM, Anna Zaks wrote:
>> 
>>> On Feb 5, 2016, at 6:15 AM, Craig, Ben < <mailto:ben.craig at codeaurora.org>ben.craig at codeaurora.org <mailto:ben.craig at codeaurora.org>> wrote:
>>> 
>>> On 2/4/2016 5:52 PM, <Alexander G. Riccio> wrote:
>>>> Consider making "no detailed analysis" an option for -enable-analyze-pass to help with these use cases
>>>> 
>>>> Eh? Do you mean less detailed output or less detailed analysis done by clang?
>>> I mean analysis that just emits diagnostics on the console, but doesn't emit a .plist or .html report.
>> 
>> 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? 
>> 
> 
> If you have a large, "dirty" code base, then the test output on its own isn't going to be terribly useful.
> 
> 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...
> 
>   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'}}
> 

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.

> That warning text on the command line is useful by itself, especially if it is fresh code.
> 
> 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.
> 
> -- 
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160205/f880a4e7/attachment.html>


More information about the cfe-dev mailing list