[cfe-dev] Static analysis tool development

[Ted Kremenek]

On Jan 17, 2009, at 7:02 AM, Ben Laurie wrote:

> On Sat, Jan 17, 2009 at 2:53 PM, Monty Zukowski <monty at codetransform.com 
> > wrote:
>> I'm glad to hear all the details of your analyzer.  I'll have more
>> questions later, I'm sure, but for now this is what interests me  
>> most:
>>
>>> 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.
>>
>> As you mentioned later, issue tracking is very important and the
>> analyzer can be designed to help with that.
>
> I do wonder if suppression of false positives is better done by
> annotation than by tracking...
>
> a) The annotation can be reused by other analysers.
>
> b) The annotation works for developers who start from scratch.

I personally like annotations.  They represent "actionable  
documentation" that can be leveraged by multiple tools.

That said, in my own conversations with different developers I have  
seen cases where annotations directly in the source code are  
completely taboo.  Probably the best example is source code that is  
under a tight "change control" process where only critical changes can  
be made to the source code.  Being able to "annotate" code, be it for  
issue tracking or enhancing a tool's knowledge of the code, without  
actually *modifying* the code is really useful in such circumstances.   
This allows code to be actively scanned and "annotated" without source  
modifications.  Alternatively, one may wish to back-scan previous  
versions of a code base to determine when certain issues appeared.   
Earlier versions of a code base wouldn't certainly lack any  
annotations embedded in the code itself.

That said, source-level annotations are the easiest to support (from  
an engineering perspective) and probably most accurate form of  
documentation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20090119/8dd58888/attachment.html>