Static Analysis: results of FUDcon Lawrence hackfest

[Kamil Dudka]

On Friday, January 25, 2013 18:17:09 Richard W.M. Jones wrote:
> On Fri, Jan 25, 2013 at 10:35:29AM -0500, David Malcolm wrote:
> > As Kamil points out elsewhere in this thread, what we need are automated
> > tools that can run on code and emit warnings, without needing human
> > intervention.
> 
> My point was that there are two sorts of analysis.  The kind which is
> common to all C programs, eg. ensuring that a program doesn't
> double-free memory.  And invariants that apply only to specific
> programs, like the libvirt testing that Dan & I did:
> 
> This is the point I was trying and obviously failing to make here:
> 
> http://lists.fedoraproject.org/pipermail/devel/2012-December/175324.html

If you have a static analysis tool specific to a single package, which is fast 
enough to run during the build, then hooking the tool directly to the %check 
section of the specfile sounds like the best thing to do.

What this thread was originally about (as far as I understood it) is a
mock-based infrastructure that takes any SRPM and outputs a list of bugs.  
Hence, the set of tools used should be generic enough to apply on most of
the packages.  Passing all packages through a checker that is applicable
on a single package is inefficient.

Still, making the specialized static analysis tools use the same format for 
reporting bugs would be useful, so that the results can be processed by the 
same tools (e.g. codescan-diff to detect added/fixed bugs between versions).

Kamil