我正在从事一个项目,我在 UNIX 环境中使用 C 进行编码。我一直在使用 lint 工具检查我的源代码。Lint 已经存在了很长时间(自 1979 年以来),任何人都可以建议我可以使用的更新的代码分析工具吗?最好是免费的工具。
15 回答
不要忽视编译器本身。阅读编译器的文档并找到它可以提供的所有警告和错误,然后尽可能多地启用对您有意义的。
还要确保告诉您的编译器将警告视为错误,以便您被迫立即修复它们(-Werror
在 gcc 上)。顺便说一句,不要被-Wall
gcc所愚弄并不会启用所有警告。
你可能想检查一下valgrind
(免费!)——它“自动检测[s]许多内存管理和线程错误,并详细分析你的程序。” 它不是静态检查器,但它是一个很棒的工具!
对于 C 代码,您绝对应该使用Flexelint。我用了将近 15 年,并且发誓。它具有的真正出色的功能之一是可以通过代码中的注释(“/* lint -e123*/”)有选择地关闭和打开警告。当您想要一些与众不同的东西时,这被证明是一个强大的文档工具。“我正在关闭警告 X,因此,我这样做是有充分理由的。”
对于任何遇到有趣的 C/C++ 问题的人,请查看他们网站上的一些示例,看看您是否可以在不查看提示的情况下找出错误。
我听说过关于clang static analyzer的好消息,IIRC 使用 LLVM 作为后端。如果这在您的平台上实现,那可能是一个不错的选择。
据我了解,它不仅仅是语法分析。例如,“自动查找错误”。
您可以使用cppcheck。它是一个易于使用的静态代码分析工具。
例如:
cppcheck --enable=all .
将检查当前文件夹下的所有 C/C++ 文件。
我们一直在使用Coverity Prevent来检查 C++ 源代码。
它不是一个免费工具(尽管我相信他们为开源项目提供免费扫描),但它是您能找到的最好的静态分析工具之一。我听说它在 C 上比在 C++ 上更令人印象深刻,但到目前为止它帮助我们避免了相当多的错误。
类似 Lint 的工具通常会遇到“误报”问题:它们报告的问题比实际存在的要多得多。如果真正有用的警告比例太低,用户就会学会忽略该工具。更现代的工具会花费一些精力来关注最可能/最有趣的警告。
PC-lint/Flexelint是非常强大和有用的静态分析工具,并且高度可配置,但遗憾的是不是免费的。
当第一次使用这样的工具时,他们会产生大量的警告,这使得很难区分主要和次要的警告。因此,最好在项目的早期就开始在您的代码上使用该工具,然后尽可能频繁地在您的代码上运行它,这样您就可以在出现新警告时进行处理。
通过像这样的持续使用,您很快就会学习如何以符合该工具应用的规则的方式编写代码。
正因为如此,我更喜欢像 Lint 这样运行相对较快的工具,因此鼓励持续使用,而不是更繁琐的工具,你可能最终会很少使用,如果有的话。
lint会不断更新……那你为什么想要一个更新的。
BTW flexelint是lint
天,
我完全同意在设置 -Wall 后阅读和消化编译器告诉你的内容的建议。
一个很好的安全静态分析工具是David Wheeler 编写的FlawFinder 。它在寻找各种安全漏洞方面做得很好,
但是,它并不能取代让知识渊博的人阅读您的代码。正如大卫在他的网页上所说,“有工具的傻瓜仍然是傻瓜!”
干杯,
抢
我发现通常最好使用多个静态分析工具来查找错误。每个工具的设计都不同,它们可以找到彼此非常不同的东西。
在这里的一些谈话中有一些很好的讨论。它来自美国国土安全部举行的关于静态分析的会议。
Sparse是一种计算机软件工具,已经在 Linux 上可用,旨在发现 Linux 内核中可能存在的编码错误。
Linux 验证中心有两个活跃的项目旨在提高可加载内核模块的质量。
- Linux 驱动程序验证 (LDV) - 用于对 Linux 设备驱动程序进行静态源代码验证的综合工具集。
- KEDR Framework - 用于动态分析和验证内核模块的可扩展框架。
- 另一个正在进行的项目是 Linux 文件系统验证,旨在开发用于验证 Linux 文件系统实现的专用工具集。
gcc 有一个“-Weffc++”选项,根据 Mac OS X 手册页,该选项将:
警告违反 Scott Meyers 的 Effective C++ 书中的以下样式指南:
[剪辑]
我知道你问过 C,但这是我所知道的最接近的..