Quick summary: use this tool:
http://clang-analyzer.llvm.org/
If you're not using its "scan-build" tool, then start. Right now.
Really. It's that good.
Recently I've run it on a variety of packages, from coreutils
(of course) to libvirt -- and libxml2 on request by the maintainer.
To use them, build the tools described here, from source:
(currently, there is no fedora package, afaik)
http://clang-analyzer.llvm.org/
I ran them like this for libxml2:
scan-build -o clang ./autogen.sh
scan-build -o clang make
The -o clang says to put the summary in a directory named "clang".
The file you'll want is named e.g., clang/2009-09-04-1/index.html
The resulting HTML:
http://meyering.net/code/tmp/clang/libxml2-vs-clang-syntax-checker/index....
is essentially the clang/ directory specified by the commands above.
Note that some of the things it reports are definitely false positives,
but if it's confused enough by your code to think that some part could
dereference NULL, then a human reviewer might make the same mistake.
In some cases it's a good indication you can make the code cleaner.
The second "bug" I looked at was a doosey:
http://meyering.net/code/tmp/clang/libxml2-vs-clang-syntax-checker/report...
doc = cur->doc; { // curly on wrong line
if (doc != NULL) // no curly brace
oldenc = doc->encoding; // one-line "then" clause
if (ctxt->encoding != NULL) { // not part of "if block"
doc->encoding = BAD_CAST ctxt->encoding;
} else if (doc->encoding != NULL) {
encoding = doc->encoding;
}
}
Also note the section on "dead store" bugs.
At first glance, you might think you can blindly
remove the offending statement or expression.
Don't do that. At least not "blindly".
For example, one dead store bug in libvirt exposed
an interface bug that made it so a function would always
return zero, rather than -1 upon failure.