[cfe-dev] Static analysis tool development

[Ryan Govostes]

> From: Ted Kremenek <kremenek at apple.com>
> Date: January 16, 2009 3:42:34 PM PST
> To: Monty Zukowski <monty at codetransform.com>
> Cc: Ben Laurie <benl at google.com>, cfe-dev at cs.uiuc.edu
> Subject: Re: [cfe-dev] Static analysis tool development
> Reply-To: kremenek at apple.com
>
...
>
> Another high-level goal of the analyzer is to support the relaying  
> of rich diagnostics to end-users about how a bug manifests in their  
> program.  The diagnostic reporting mechanism in the analyzer also  
> uses a set of abstract interfaces so that bug reports can be  
> rendered in a variety of ways (e.g., to the console, to an HTML  
> page, within an IDE, etc.).  Providing rich diagnostics is an  
> important goal because without them the results of a static analysis  
> algorithm is only useful to graduate students studying program  
> analysis techniques rather than programmers who want to fix bugs.
>
...
>
> "Issue tracking" would useful for a wide range of clients.  To do  
> this well, however, I don't think it can be done completely separate  
> from the analyzer.  Issue tracking requires rich diagnostics that  
> describe a bug but also must be insensitive to code churn that has  
> no bearing on a particular bug or false positive.  In some cases  
> this may require issuing queries to the analyzer to extract more  
> information.  As a first cut, however, the output could be based  
> entirely on the diagnostics.
>
> As an interesting side note, the developers of Adium (http://www.adiumx.com 
> ) have actually been regularly scanning their sources using Clang's  
> static analyzer.  As part of their process, they wrote some scripts  
> that inspect the emitted diagnostics (in this case HTML files) and  
> did some munging to determine if the a report emitted on a given  
> scan was the same as in a prior scan.  Their goal is to avoid re- 
> inspecting previously diagnosed bugs and false positives.  Having a  
> general mechanism in the analyzer library would be quite useful, and  
> would be a good first order project for anyone who is interested in  
> getting involved.
>

I thought I'd chime in here; I wrote the scripts we currently use in  
Adium for this purpose. Sources (which do not work with the latest  
version of Clang, to my knowledge) are at: http://trac.adiumx.com/browser/trunk/Utilities/Analyzer

In response to the above paragraphs of Ted's e-mail, I thought I'd  
announce here that I've been working on a Trac plugin for viewing  
Clang reports. Recent versions of the analyzer will output to plist  
files, or HTML files, but not both (though this would presumably be a  
trivial change). The Trac plugin parses plist files to generate a file  
view, which is annotated with the appropriate diagnostics.

Using a dynamic view (i.e., the one generated by Trac) to view the  
reports has some benefits over the static files. For one, we can strip  
parts of the code that are irrelevant to the report, instead showing  
only a few context lines above and below each diagnostic. Another  
thing we can do is add links to other pages, such as a report  
generated on a previous revision of the file.

More importantly, however, is the possibility to automatically file  
tickets based on new bugs. The system can track a single bug  
longitudinally across several commits, using simple heuristics to  
decide when a report has been resolved, or merely changed. (This would  
integrate well with a system like Buildbot for performing scan builds  
and uploading new plists.)

Is there any interest in a plugin like this? I'd be glad to share it  
on a repository if anyone would like to help flesh out the idea.

---

Ryan Z. Govostes

Rensselaer Polytechnic Institute
Computer Science '11

Vice President				RPISEC Cyber Security Club
Managing Editor				The Rensselaer Polytechnic
Undergraduate Researcher	CogWorks Laboratories
Member						Upsilon Pi Epsilon