如何在Frama-C GUI中使用Why3样张?

时间:2015-09-17 08:57:47

标签: frama-c why3

这感觉就像一个愚蠢的问题,但我很难过。我尝试使用Frama-C Sodium和Why3 0.86.1(都通过OPAM安装)来证明一些简单的属性。考虑一下这个程序(toy.c):

int main(void) {
    char *hello = "hello world!";
    /*@ assert \valid_read(hello+(0..11)); */
    return 0;
}

我想使用Frama-C GUI和Why3来证明这个断言。所以我运行frama-c-gui toy.c,选择" Why3(ide)"作为证明者和运行"证明WP"的功能注释;关于主要功能。 (或者:我导航到" WP目标"选项卡并从那里运行Why3 IDE。)Why3出现,我调用我选择的证明器将所有内容变为绿色,保存会话并退出Why3,然后在Frama-C GUI中没有任何反应:该属性仍标记为橙色/"试图验证但无法决定"。

我如何告诉Frama-C实际使用Why3生成的样张?证明本身肯定存在:如果我再次打开Why3,一切都仍然是绿色,所以会话保存得当。此外,Frama-C知道发生了某事:当Why3 IDE打开时,WP目标选项卡中会显示一个小齿轮符号,当我关闭Why3时它会消失。

(我意识到Alt-Ergo可以证明这个特殊属性而不涉及Why3,但我确实需要Why3来解决更难的问题。)

2 个答案:

答案 0 :(得分:2)

对我自己的初步回答:看起来Frama-C的Why3会话XML文件的解析器与Why3 0.86.1生成的XML不匹配。这个补丁似乎解决了这个问题:

diff -ur frama-c-Sodium-20150201/src/wp/why3_session.ml frama-c-Sodium-20150201-hacked/src/wp/why3_session.ml
--- frama-c-Sodium-20150201/src/wp/why3_session.ml  2015-03-06 16:28:27.000000000 +0100
+++ frama-c-Sodium-20150201-hacked/src/wp/why3_session.ml   2015-09-17 21:35:30.717409735 +0200
@@ -160,6 +160,20 @@
   let name = string_attribute "name" elt in
   name

+let load_result parent_goal r =
+  match r.Xml.name with
+  | "result" ->
+      let status = string_attribute "status" r in
+      assert (parent_goal.goal_verified = false);
+      parent_goal.goal_verified <- (status = "valid")
+  | _ -> ()
+
+let load_proof parent p =
+  match p.Xml.name with
+  | "proof" ->
+      List.iter (load_result parent) p.Xml.elements
+  | _ -> ()
+
 let rec load_goal parent g =
   match g.Xml.name with
   | "goal" ->
@@ -168,7 +182,9 @@
       let mg =
         raw_add_no_task parent gname
       in
-      mg.goal_verified <- verified
+      mg.goal_verified <- verified;
+      (* hack for different(?) session file format *)
+      List.iter (load_proof mg) g.Xml.elements
   | "label" -> ()
   | s ->
       Wp_parameters.debug

不保证这对任何其他人都有用(或者即使我认为这对我自己的用途也是正确的。)

任何机会的Frama-C开发者都可以发表评论吗?

答案 1 :(得分:1)

感谢您报告错误。提议的修复似乎有效。

但是,我们希望与Why-3会话更紧密地整合,并导回Frama-C,证明者履行了每项证明义务。实际上,我们将在重构期间修复错误。