让静态分析更容易些

翻译：林业

有件事几年来已经很清楚了，那就是静态分析工具有极大的提高我们所编写软件的质量的潜力，计算机有条件分析源代码并且寻找那些可以标示漏洞的 patterns。“Stanford Checker”(后来被 Coverity 商业化了)已经在许多免费软件代码库中找到了大量的缺陷。但就是在免费软件社区之内，我们自己开发的工具相对缺乏并且比较原始，不过，这种情况或许已经要结束了，我们已经开始看到若干可能成为静态分析工具集基础的开发框架了。

一些关键的变动已经出现在编译器套件中。编译器目前已对代码执行了详细的分析来生成优化的2进制码；如果利用那些分析来做其它的事情是很自然的。其中的一些已经出现在编译器本身之内；GCC和LLVM可以生成一个比以往更广泛的警告集。这些警告是一个好的开始，但是还有更多的事可以去做，特别是让一个项目可以生成自己专有的项目检查分析工具。因为无论什么大小规模的项目都趋向于拥有自己本身的而与其他不同的不变量和规则。

几年来FSF一直反对将分析模块通过插件机制添加到GCC，因为害怕插件机制会允许私有模块的产生。经过几年时间的考虑，因为对专有模块处理的担忧，FSF改写了运行时模块的许可证例外部分；到这时，GCC才有了对插件模块的支持。虽然这个特性的作用现在还相对较小，但却是一个情况即将改变的标志。

Mozilla项目是一个对插件机制较早的使用者，它创造了两个模块（Dehydra and Treehydra）来让开发者编写用Javascript写出的分析代码。这些工具已经展示出了其在Mozilla之内的作用，但是这方面的开发似乎停止了。其邮件列表处于垂死状态并且其软件看起来也似乎好久没有更新了。

一个替代的选择是GCC MELT。这个项目提供了一个相当广泛的插件地址以允许使用类Lisp语言来编写分析代码，这份代码被转换成C语言，然后编译出一个可被编译器调用的插件。MELT有很好的文档；以及许多关于其应用教程的幻灯片。

MELT看起来似乎是一个能胜任的系统，但是看起来似乎并没有太多为其而写的模块。人们并不希望必须看很多文档后才能理解该系统。基本提示是以如下开头的：“首先你要理解 GCC的主要内部表现(notably Tree & Gimple & Gimple/SSA)。”MELT作者Basile Starynkevitch的130页关于MELT的讲解幻灯片的前85页全都是介绍GCC材料。换一种说法，使用MELT需要对GCC有深入的理解；其并不是一个行外人士可以快速上手的系统，可以使用的简单示例的缺乏也同样是没什么帮助。

最近，David Malcolm宣布了一个新的框架的发布，该框架允许产生一些与编译器共同运行的Python脚本插件。他的原始目标就是要创造一些帮助 Python 项目(CPython)开发的工具。其代码中最重要的检查部分就是在努力确保对象的引用计数被正确的管理。但是他认为自己的工具对其它的一些项目甚至是对GCC本身的新特性设计也是有潜在作用的。

第一眼看上去，David的gcc-python-plugin机制承受着和MELT一样的困难 - 最初的学习曲线是不合理的。它同样是一个很年轻且不完整的项目；David自己也承认，只推出了他急需的功能性的部分。分析代码看起来很接近了，可是，在编译器中直接运行脚本的机制确实比MELT的compile-from-Lisp要自然些。相比MELT，这可能会吸引更多的用户和开发人员吧。

或许它只是因为小编本人使用 Python 比在Lisp中更加熟练，所以偶自然而然的觉得基于Python是一个更好的解决方案。

无论如何，有一个结论是很清楚的：目前为GCC编写静态分析插件太难了；甚至是有才华的开发者在接触到这个问题时也需要花费很多的时间去理解编译器，才可能在这个领域取得一些成就。上面描述的这些努力是在正确方向上的一个很大的进步。很明显，现在的努力是需要在其上构建许多支持代码的基础。很难说我们什么时候才能到达那个分析代码大量涌出的临界点，现在离那个时候还很遥远。

不过，并不是所有的活动都在围绕着GCC，一个利用LLVM编译器的有趣的静态分析工具已经随着 clang 被构建出来了。关于这个工具的文档几乎没有，但是看起来它在某些方面还是很强大的，比如检测某些内存泄漏问题，间接的空指针引用，闲置价值的计算等等。一些为这个工具增加一个插件特性的补丁包也已经被贴出，但是看起来似乎它们目前也并没有走的更远。

在5月的时候，John Smith在一些开源项目中运行了 clang 想要看看会得到什么样的结果。这些结果已经被贴到了网上，它们显示了一些可被找到的潜在的问题以及检查器所产生的漂亮的HTML输出。其中一些警告明显是无效的——一个经常伴随着静态分析工具的问题——但是另外的一些看起来很值得去研究。总而言之，clang 静态分析工具看起来就像这里提到的其他工具一样，在发展过程中还处于一个相对较早的阶段，虽然所有东西都在快速运行着，但是这个工具是值得关注的。

事实上，一般而言，在静态分析领域，以下这些事情是真的：缺乏一个好的分析工具有点奇怪——考虑到我们有那么多的开发人员，有的人可能认为只需要很少人就能搞出一个静态分析工具。相比较于已经存在很多的版本控制系统，我更希望开发者去开发更好的分析工具。但是自由软件开发的天性就是人们工作在那些使他们感兴趣的问题上。随着我们静态分析工具的基础越来越好，可以期待越来越多的开发人员将会找到他们感兴趣的基础，并且乐于在其之上进行构建。而整个开发社区也会从这些结果中受益。