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 > [email protected] > http://lists.x.org/mailman/listinfo/xorg-devel _______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
