我正在做一个相当复杂的项目，作为一个额外的复杂性，它是一个内核 Linux 模块。在这样的代码库上运行像夹板这样的 linting 工具当然不是不可能的 [1]，但是微不足道的努力还不足以让事情顺利进行。
在我投入更多时间之前，我希望能就这个问题获得一些反馈和意见。有了足够多的标志，gcc 会进行大量检查。在实践中使用单独的静态代码分析工具是否仍然值得？
[1] http://www.cs.virginia.edu/pipermail/splint-discuss/2005-January/000531.html
除了像这样的工具sparse，我建议看看LDV 项目。LDV 首先是面向检查 Linux 驱动程序的。该系统执行比静态分析更深入的分析splint，sparse并且可以检测到非常难以捉摸的问题。
LDV 是免费软件。
如果您想尝试但没有时间部署它，他们提供在线验证服务，您可以在其中上传代码并进行检查。
除此之外，Coccinelle系统可能也值得一看。与 LDV 一样，Coccinelle 被用于检测 Linux 内核中的许多不同错误。
虽然splint绝对是整洁的，但我认为在 Linux 内核源代码上使用它所需的努力可能比它所能返回的要多。
但是，内核开发人员有自己的sparse工具来执行一些类似的检查，并且已经将其使用深度集成到内核源代码中。将它集成到您的源代码中也应该感觉很自然，因为它已经遍布内核源代码。有关Documentation/sparse.txt使用的详细信息，请参阅sparse。
有一个商业项目Coverity偶尔会扫描许多“高度重要”的开源项目以查找问题。他们使用他们的工具在 Linux 内核源代码中发现了数百甚至数千个错误。（这是一个快乐的故事，他们为他们的产品做广告，美国政府获得了大量极其重要的代码审查，开源作者获得免费的错误报告，开源用户获得免费代码审查的好处。四方胜利！）
购买 Coverity 的专业知识对您来说是否值得是另一个问题——但是与它集成sparse将为您带来静态代码检查工具的一些好处，而无需支付许可费用。