Someone from Coverity recently gave a talk to the local Unix hacks group about their static analysis tools, and in the process got me to thinking about the different types of bugs that I see.

As a first approximation, I think that I can split relatively common bugs into three different classes:

• mistakes like using the wrong variable or off by one errors.
• oversights like forgetting to free memory or unlock a lock under some circumstances.
• logic errors, where the code is accurately expressing your desire and you got all the details right, it's just you're doing the wrong thing.

(As always, the boundaries between classes can be fuzzy.)

Simple static analysis can find mistakes and straightforward oversights. More sophisticated analysis (on the level of Coverity's tools and the Linux kernel tool sparse) can pick up more oversights, although some involve sufficiently dynamic stuff that they can only be spotted through runtime analysis.

I think that true logic errors can generally not be caught by an analysis program, partly by definition. At best an analysis program might be able to determine that what the code is doing is nonsensical or pointless. To do better we would need some way of telling the static analysis program what the code should be doing, which is basically an unsolved problem.

(Tests, unit and otherwise, are one form of mapping out what the code should be doing. Given that some code is very difficult to unit test, I can imagine a static analysis tool for checking test cases in various ways.)