软件验证的逻辑

Question

我正在考虑自动软件验证的要求，即一个接受代码的程序（用C和Java等语言编写的普通程序代码），生成一堆定理，说每个循环必须最终停止​​，没有断言将被违反，将永远不会取消引用空指针等，然后将其传递给定理证明器以证明它们实际上是真的（或者找到表示代码中的错误的反例）。

问题是使用什么样的逻辑。两个主要职位似乎是：

1. 一阶逻辑就好了。

2. 一阶逻辑不够表达，你需要更高阶的逻辑。

问题是，似乎对这两个职位都有很多支持。那么哪一个是对的？如果它是第二个，是否有任何可用的事情示例，基于一阶逻辑的验证器有问题？

Answer 1

你可以在FOL做你需要的一切，但这是一项额外的工作 - 很多！大多数现有系统是由学者/人员开发的，时间不多，所以他们很想采取捷径来节省时间/精力，因此被HOL，函数式语言等所吸引。但是，如果你想建立一个数十万人使用的系统，而不仅仅是数百人，我们认为FOL是一种可行的方式，因为它更容易被更广泛的受众所接受。做这项工作是无可替代的;我们已经在这25年了！请看一下我们的项目（http://www.manmademinions.com）

问候，亚伦。

Answer 2

根据我的实际经验，它似乎是“1.一阶逻辑就好了”。有关完全以基于一阶逻辑的规范语言编写的各种函数的完整规范示例，请参阅例如ACSL by Example或this case study。

一阶逻辑具有多年来经过改进的自动化证明器（不是证明助手），以处理来自程序验证的良好属性。这些用途的值得注意的自动化证明是例如Simplify，Z3和Alt-ergo。如果这些证明失败并且没有明显的引理/断言，你可以添加来帮助他们，你仍然可以求助于为难以证明的义务启动证明助手。另一方面，如果你使用HOL，你根本不能使用Simplify，Z3或Alt-ergo，虽然我听说过高阶逻辑的自动化校准，但我从未听说过它们在属性方面的效率。来自节目。

Answer 3

我们发现FOL适用于大多数验证条件，但更高阶逻辑对于少数验证是非常宝贵的，例如用于证明集合中元素求和的属性。所以我们的定理证明器（在Perfect Developer和Escher C Verifier中使用）基本上是一阶的，但也有能力做一些更高阶的推理。