Clang static analyzer

[Oliver McFadden]

On Tue, 2009-12-08 at 06:55 +0100, ext Tomas Carnecky wrote:
> On Dec 8, 2009, at 1:52 AM, Tiago Vignatti wrote:
> 
> > Tomas Carnecky wrote:
> >> On Dec 7, 2009, at 10:32 PM, Brian Paul wrote:
> >>> Tomas Carnecky wrote:
> >>>> During the past two days I played with the clang static analyzer. Clang is a C/C++ compiler based on LLVM. The clang static analyzer makes use of clang and the LLVM infrastructure to perform static analysis on C source code. I wrote a blog post [1] about my experience with it so far.
> >>>> I tested the static analyzer on a few opensource projects, one of which was the xorg xserver. The results (333 potential bugs) are available on my web server [2]. I skimmed only quickly over the results and they need careful review to find out which ones are actual bugs. Some of the issues are very easy to review (dead assignments, dead increments), others not so much.
> >>>> I could run the analyzer on other parts of the xorg stack (mesa, drivers, libraries) if there is interest.
> >>> I'd be interested in the results for Mesa.
> >> Sure, I've just set up the infrastructure to run the clang analyzer on all modules listed in util/modular/plain/xorg.modules. Are there any additional configure or make flags you want me to use when building mesa? Right now the scripts are set up to run the standard ./configure && make, but I can add per-module flags or options. 
> > 
> > Would be nice to set up this frequently and post the results on X wiki.
> 
> I can run the script regularly, that's no problem. But interpreting
> the data takes a lot of time. Finding the real bugs amongst the many
> false positives is incredibly time consuming.

Maybe it would be worth doing a bit of perl (or your favorite
language :) to white-list known false positives and filter them out. Eg
based on line number (perhaps +/- N lines to take care of changes - of
if it was really smart, track git changes) and type of error. At least
this way you don't have to start from scratch after every invocation of
clang.

Unfortunately, it's been a while since I've done perl, so I'm just
throwing the idea out there.

> 
> I also posted the analyzer results of the git source on their mailing list and suggested that if we were to further cut down the number of false positives we'd need to add annotations (if/then/else branches or assertions) to help the analyzer better understand the code. The consensus seems to be that the source should not be cluttered with such annotations which I have to agree with. After all, clang is just one of many such tools, and I don't want to imagine how the source code would have to look if we had to cater for every single of such static analysis tools.
> 
> Btw, the results are up at [1].
> 
> > If you are able to do so, then someone should set up an account for you at annarchy.fd.o (better poke someone and raise up this on #xorg-devel).
> 
> You mean so I can publish the results on annarchy.fd.o?
> 
> tom
> 
> 
> [1] http://78.46.209.101/stuff/clang-static-analyzer/fdo/
> _______________________________________________
> xorg-devel mailing list
> xorg-devel at lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-devel