静态分析中的自动执行是否提供所需

软件开发活动应包括源代码审查，以提高软件质量并防止或消除软件缺陷，静态分析工具可以自动化该活动的重要部分，同时降低其成本。代码审查通常基于定义应识别和纠正哪些违规或缺陷的编码标准和/或检查表进行。

尤其是 C 语言，编码标准的流行示例是 MISRA C 和 CERT C，它们分别提供了增强安全性和安全性的指南（尽管这两个范围之间存在一些重叠）。MISRA C 指南的制定特别关注其静态分析的可执行性，这反映在可以自动实现的大量执行中。

但是，有两个不可避免的限制阻碍了全自动执行：

1. 在某些情况下，将静态分析器完全执行准则所需的所有信息形式化是不切实际的或不可能的。

2. 对于某些准则，即使所有信息都可用于算法，即使算法可以扩展以清除任何特定的假阳性或假阴性。

在最新版本的 MISRA C （2012） 中，这些限制反映在指南的分类中。当可以提供足够的信息时，将指南归类为规则；否则，它被归类为指令。当可以构造通用算法时，将规则分类为可判定的；否则，它被归类为不可判定。

指南有不同的优先级和不同的范围，但为了初步了解自动执行的潜在程度，159 条指南分为 16 条指令、27 条不可判定规则和 116 条可判定规则。

指令的一个示例是所有代码都应可追溯至文件化要求。在这种情况下，仅向静态分析器提供整个源代码和用于构建应用程序的编译器配置是不够的。首先，将任何重要的要求形式化是不切实际的或不可能的。

可判定规则的一个示例是不应使用#undef。在这种情况下，可以构造一个算法来扫描任何源代码并报告所有出现和仅出现#undef 预处理指令的情况。

不可判定规则的一个例子是项目不应包含无法访问的代码。你能想象一个算法可以精确识别任何项目中所有无法访问的代码实例吗？

不可判定性可能是一个相当不直观的概念。软件开发人员通常会面临一系列需要解决的问题，从微不足道到不可能，其中可以实现的限制通常由熟悉的因素决定，例如缺乏信息、问题过于复杂、资源消耗急剧增加域范围等

除了所有这些因素之外，编码标准的自动执行（或任何其他自动检测软件缺陷的非正式方式）涉及构建原则上可以自我分析的算法，这会引入一个循环性，如果一个额外的基本限制会导致一个悖论 - undecidability - 不妨碍构建一个健全和完整的分析仪。

审核编辑：郭婷