A useful feature of cppcheck is the --force option that will check against all the configurations in the source (and the kernel does have many!). This allows us to check for code that may not be exercised much (because it is normally not built in with most config options) or even find dead code.
The downside of using the --force option is that each source file may need to be checked multiple times for each configuration. For ~20800 sources files this can take a 24 processor server several hours to process. Errors and warnings are then compared to previous runs (a delta), making it relatively easy to spot new issues on each run.
We also use the latest sources from the cppcheck git repository. The upside of this is that new static analysis features are used early and this can result in finding existing bugs that previous versions of cppcheck missed.
A typical cppcheck run against the linux kernel source finds about 600 potential errors and 1700 warnings; however a lot of these are false positives. These need to be individually eyeballed to sort the wheat from the chaff.
Finally, the data is passed through a gnu plot script to generate a trend graph so I can see how errors (red) and warnings (green) are progressing over time:
..note that the large changes in the graph are mostly with features being enabled (or fixed) in cppcheck.
I have been running the same experiment with smatch too, however I am finding that cppcheck seems to have better code coverage because of the --force option and seems to have less false positives. As it stands, I am finding that the most productive time for finding issues is around the -rc1 and -rc2 merge times (obviously when most of the the major changes land in the kernel). The outcome of this work has been a bunch of small fixes landing in the kernel to address bugs that cppcheck has found.
Anyhow, cppcheck is an excellent open source static analyzer for C and C++ that I'd heartily recommend as it does seem to catch useful bugs.
