Question

I’m working on a fairly complex project, and as an added complication it’s an in-kernel Linux module. Running a linting tool like splint on such a codebase is certainly not impossible [1], but trivial effort was not enough to get something going.

Before I invest more time into this, I was hoping to garner some feedback and opinions on the issue. With enough flags, gcc does quite a lot of checking. Is using a separate static code analysis tool still worth it in practice?

[1] http://www.cs.virginia.edu/pipermail/splint-discuss/2005-January/000531.html

Answer 1

While splint is definitely neat, I think the effort required to use it on Linux kernel sources is probably more than it would return.

However, the kernel developers have their own sparse tool for performing some similar checks and have already deeply integrated its use into the kernel sources. Integrating it into your sources too should feel pretty natural, since it is already all over the kernel source code. See Documentation/sparse.txt for details on using sparse.

There is a commercial project, Coverity, that occasionally scans many “high importance” open source projects for problems. They’ve discovered hundreds, if not thousands, of bugs in the Linux kernel sources with their tool. (It is a happy story of them advertising their product, the US government getting a giant pile of extremely important code reviewed, open source authors getting free bug reports, and open source users getting the benefits of free code reviews. A four-way win!)

Whether or not it is worth it to you to purchase Coverity’s expert knowledge is another question — but integrating with sparse will get you some of the benefits of static code checking tools without the licensing fees.