静态分析仪应分析哪些级别？

这些不同的方面可以影响分析仪决定工作的水平： 设计静态分析仪需要做很多工作。将这项工作归结为编译为相同字节码的几种语言将是一种耻辱，特别是当字节码保留源程序的大部分结构时：Java（FindBugs），.NET（与代码合同相关的各种工具）。在某些情况下，虽然编译方案没有遵循这条路径，但共同的目标语言是为了分析而编写的。 与1相关，您可能希望如果静态分析器在具有最少数量构造的程序的规范化版本上工作，则编写成本会稍微低一些。在编写静态分析仪时，必须在写入

while do

时写入

repeat until

的处理是一件麻烦事。您可以构建分析器，以便为这两种情况共享多个函数，但处理此问题的轻松方法是将一个函数转换为另一个，或者将源转换为仅包含其中一个的中间语言。 另一方面，正如Flash Sheridan的回答中已经指出的那样，源代码包含的信息最多。例如，在具有模糊语义的语言中，可以通过编译来消除源级别的错误。 C和C ++有许多“未定义的行为”，允许编译器做任何事情，包括生成一个意外工作的程序。很好，您可能会认为，如果错误不在可执行文件中，那么这不是一个有问题的错误。但是，当您为另一个体系结构或下一版本的编译器重新编译该程序时，该错误可能会再次出现。这是在可能消除错误的任何阶段之后不进行分析的一个原因。 只能在编译代码上以合理的精度检查某些属性。这包括Flash Sheridan再次指出的缺少编译器引入的错误，但也包括最坏情况的执行时间。类似地，除非您查看编译器生成的程序集，否则许多语言都不会让您知道浮点代码的确切行为（这是因为现有硬件不便于它们保证更多）。然后选择编写一个不精确的源级分析器，该分析器考虑所有可能性，或者精确分析浮点程序的一个特定编译，只要理解它是将执行的精确汇编代码即可。 。     

当然，源代码分析是最常用的;有时，启发式甚至需要分析评论或格式。但你是对的，即使是对象代码分析也是必要的，例如，检测由GCC错误引入的错误。 GrammaTech的负责人和威斯康星州教授Thomas Reps几年前在斯坦福大学就此进行了很好的讨论：http：//pages.cs.wisc.edu/~reps/#TOPLAS-WYSINWYX。