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
Cppcheck is a static analysis tool for C/C++ code. It provides unique code analysis to detect bugs and focuses on detecting undefined behaviour and dangerous coding constructs.
Helix QAC is an excellent static analysis testing tool for C and C++ code from Perforce (formerly PRQA). The tool comes with a single installer and supports platforms like Windows 7, Linex Rhel 5 and Solaris 10.
Klocwork. Klocwork can perform static code analysis on projects of almost any size. The primary benefit of using Klocwork is that it is easily integrable with Visual Studio Code IDE, Eclipse, IntelliJ, and a few others. This makes use of Klocwork easier for developers.
SonarQube is the popular static analysis tool for continuously inspecting the code quality and security of your codebases and guiding development teams during code reviews.
In addition to the tools like sparse
, I would suggest taking a look at LDV project. LDV is oriented towards checking Linux drivers in the first place. This system performs deeper static analysis than splint
and sparse
and can detect very elusive problems.
LDV is free software.
If you would like to try it but don't have time to deploy it, they have an online verification service where you can upload your code and have it checked.
Apart from that, Coccinelle system may also be worth looking at. Like LDV, Coccinelle was used to detect many different errors in the Linux kernel.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With