frama-c - 如何在 frama-c 中调试 ACSL？

Question

我正在尝试学习 ACSL，但在尝试编写完整的规范时遇到了困难。我的代码

#include <stdint.h>
#include <stddef.h>

#define NUM_ELEMS (8)

/*@ requires expected != test;
  @ requires \let n = NUM_ELEMS;
  @          \valid_read(expected + (0.. n-1)) && \valid_read(test + (0.. n-1));
  @ assigns \nothing;
  @ behavior matches:
  @   assumes \let n = NUM_ELEMS;
  @           \forall integer i; 0 <= i < n ==> expected[i] == test[i];
  @   ensures \result == 1;
  @ behavior not_matches:
  @   assumes \let n = NUM_ELEMS;
  @           \exists integer i; 0 <= i < n && expected[i] != test[i];
  @   ensures \result == 0;
  @ complete behaviors;
  @ disjoint behaviors;
  @*/
int array_equals(const uint32_t expected[static NUM_ELEMS], const uint32_t test[static NUM_ELEMS]) {
  for (size_t i = 0; i < NUM_ELEMS; i++) {
    if (expected[i] != test[i]) {
      return 0;
    }
  }
  return 1;
}

我运行它

frama-c -wp -wp-rte test.c

我看到以下日志

[kernel] Parsing FRAMAC_SHARE/libc/__fc_builtin_for_normalization.i (no preprocessing)
[kernel] Parsing test.c (with preprocessing)
[rte] annotating function array_equals
test.c:22:[wp] warning: Missing assigns clause (assigns 'everything' instead)
[wp] 9 goals scheduled
[wp] [Alt-Ergo] Goal typed_array_equals_assign_part1 : Unknown (Qed:2ms) (67ms)
[wp] [Alt-Ergo] Goal typed_array_equals_assert_rte_mem_access_2 : Unknown (Qed:2ms) (128ms)
[wp] [Alt-Ergo] Goal typed_array_equals_assert_rte_mem_access : Unknown (Qed:2ms) (125ms)
[wp] [Alt-Ergo] Goal typed_array_equals_matches_post : Unknown (Qed:10ms) (175ms)
[wp] [Alt-Ergo] Goal typed_array_equals_not_matches_post : Unknown (Qed:7ms) (109ms)
[wp] Proved goals:    4 / 9
     Qed:             4  (0.56ms-4ms)
     Alt-Ergo:        0  (unknown: 5)

所以看来我的两种行为和“分配\无”无法得到证明。那么我该如何继续呢？

编辑:所以我解决了眼前的问题。我没有注释我的循环:

  /*@ loop invariant \let n = NUM_ELEMS; 0 <= i <= n;
    @ loop invariant \forall integer k; 0 <= k < i ==> expected[k] == test[k];
    @ loop assigns i;
    @ loop variant \let n = NUM_ELEMS; n-i;
    @*/

我更大的问题仍然存在:调试问题的好方法是什么？我通过更改和删除代码并查看已证明/未证明的内容解决了这个问题。

Answer 1

恐怕这个问题无法有明确的答案(说实话，我曾考虑过投票结束它，因为“太宽泛”)。然而，这里有一些指南可能会帮助您进行证明尝试:

识别各个条款

ACSL 规范很快由许多子句组成( requires 、 ensures 、 loop invariant 、 assert 、...)。能够轻松地区分它们非常重要。为此，您有两个主要成分:

1. 使用 GUI。它可以更容易地查看哪些注释已被证明(绿色子弹)、已被证明但假设其他未证明的子句为真(绿色/黄色)或未证明(黄色)。
2. 为子句命名:任何 ACSL 谓词都可以附加一个名称，语法为 name: pred 。当子句配备名称时，WP 将使用它来引用该子句。

常见嫌疑人

很容易错过规范中一些非常重要的部分。这是一个快速检查列表:

1. 所有循环必须配备loop invariant和loop assigns
2. 所有被分析函数调用的函数都必须有一个合约(至少有一个 assigns 子句)
3. 如果 loop assigns 中提到的内存位置不是 a 的主题对应loop invariant ，您对循环外部该位置存储的值一无所知。这可能是一个问题。

调试单个子句

一旦您确信自己没有错过任何明显的事情，就到了开始对具体条款进行调查。

1. 通常，验证 loop invariant 更容易成立(即第一次到达循环时为真)而不是保留(在循环步骤中保持为真)。如果您无法建立 loop invariant ，要么是错误的，要么你忘记了一些requires限制函数的输入(数组算法的典型情况是 loop invariant 0<=i<=n;，如果不这样做就无法证明 requires n>=0; )
2. 同样assigns和loop assigns应该比真实的功能属性更容易验证。只要它们没有全部被证明，你就应该专注于它们(一个常见的错误是忘记将循环的索引放入它的loop assigns ，或者提及它分配 a[i]而不是a[0..i] )。不要忘记assigns必须包括所有可能的分配，包括在被调用者中完成的那些。
3. 不要犹豫，使用 assert检查 WP 是否可以证明某个属性在给定点成立。这将帮助您了解问题出现的位置。 [根据下面@DavidMENTRÉ的评论进行编辑]请注意，在这种情况下，您应该注意以下事实:假设 assert 则初始证明义务可能会成功保持，而assert本身没有经过验证。在 GUI 中，这通过绿色/黄色项目符号反射(reflect)，当然还有 assert 前面的黄色项目符号。 。在这种情况下，证明还没有结束，你必须理解为什么断言没有被证明，可能使用与上面相同的策略，直到你准确地理解问题所在。