There are a wealth of powerful static analysis tools available nowadays for analyzing C source code. These tools help to find bugs in code by just analyzing the source code without actually having to execute the code. Over that past year or so I have been running the following static analysis tools on linux-next every weekday to find kernel bugs:
At the end of each run, the output from the previous run is diff'd against the new output and generates a list of new and fixed issues. I then manually wade through these and try to fix some of the low hanging fruit when I can find free time to do so.
I've been gathering statistics from the CoverityScan builds for the past 12 months tracking the number of defects found, outstanding issues and number of defects eliminated:
Using a range of static analysis tools is useful because each one has it's own strengths and weaknesses. For example smatch and sparse are designed for sanity checking the kernel source, so they have some smarts that detect kernel specific semantic issues. CoverityScan is a commercial product however they allow open source projects the size of the linux-kernel to be built daily and the web based bug tracking tool is very easy to use and CoverityScan does manage to reliably find bugs that other tools can't reach. Cppcheck is useful as scans all the code paths by forcibly trying all the #ifdef'd variations of code - which is useful on the more obscure CONFIG mixes.
Finally, I use clang's scan-build and the latest verion of gcc to try and find the more typical warnings found by the static analysis built into modern open source compilers.
The more typical issues being found by static analysis are ones that don't generally appear at run time, such as in corner cases like error handling code paths, resource leaks or resource failure conditions, uninitialized variables or dead code paths.
My intention is to continue this process of daily checking and I hope to report back next September to review the CoverityScan trends for another year.