Frama-C：Jessie插件无法证明按位或安全（w.r.t溢出）

Question

我正在使用Frama-C Nitrogen来分析以下代码

#include "/usr/share/frama-c/builtin.h"

int test()
{
    const unsigned char a = Frama_C_interval(0, 255);
    const unsigned char b = Frama_C_interval(0, 255);
    const unsigned int c = ((unsigned int)a) | ((unsigned int)b);

    return 0;
}

与

frama-c -jessie test.c

不幸的是，Jessie无法证明没有整数溢出。 特别是，无法证明以下条件（确保我正确解释输出，哪种语言是什么？我在哪里可以找到手册？）：

 0 <= bw_or(integer_of_uint32(result7), integer_of_uint32(result8))

通过查看前几行，我们也得到了：

H23: 0 <= integer_of_uint8(b) and integer_of_uint8(b) <= 429496725
H24: integer_of_uint32(result8) = integer_of_uint8(b)

Jessie不应该在H23中推断出更强大的财产吗？ 喜欢

H23: 0 <= integer_of_uint8(b) and integer_of_uint8(b) <= 255

在我看来，Jessie将中间结果视为数学整数，因此忽略了unsigned char“hint”。

我还尝试使用以下值进行价值分析：

frama-c -main test -val test.c

产生输出：

[kernel] preprocessing with "gcc -C -E -I.  test.c"
[value] Analyzing a complete application starting at test
[value] Computing initial state
[value] Initial state computed
[value] Values of globals at initialization
        Frama_C_entropy_source ∈ [--..--]
[value] computing for function Frama_C_interval <- test.
    Called from new_test.c:5.
/usr/share/frama-c/builtin.h:46:[value] Function Frama_C_interval: precondition got status valid.
/usr/share/frama-c/builtin.h:47:[value] Function Frama_C_interval: postcondition got status unknown.
[value] Done for function Frama_C_interval
[value] computing for function Frama_C_interval <- test.
        Called from new_test.c:6.
[value] Done for function Frama_C_interval
new_test.c:7:[value] assigning non deterministic value for the first time
[value] Recording results for test
[value] done for function test
[value] ====== VALUES COMPUTED ======
[value] Values for function test:
          Frama_C_entropy_source ∈ [--..--]
          a ∈ [--..--]
          b ∈ [--..--]
          c ∈ [0..255]
          __retres ∈ {0}

值分析正确地计算了c的界限，但我不明白为什么a和b的结果是近似的（不应该很容易确定？）

非常感谢任何见解。

Answer 1

  那是哪种语言？

这是版本2或版本3中的Why（转换大约是您使用的版本时）。

  

以下条件无法证明[...]：

     

0＆lt; = bw_or（integer_of_uint32（result7），integer_of_uint32（result8））

总是很难决定如何对C的按位运算符进行公理化。它完全取决于被验证程序如何使用这些运算符。 Jessie / Why验证链没有做出决定，并将这些运营商的公理化留给您。这已在前面讨论过。这个message承诺一些改进（再次，大约从氮版本的时间开始，所以要么之前或稍后）。

  

我不明白为什么a和b的结果是近似的（应该不是很容易确定？）

在值分析（选项-val）的结果中，整数类型变量的[--..--]表示此类型的所有值。变量a和b可以采用unsigned char类型的任何值，因此这些变量的值显示为[--..--]。这些结果并不近似，在这个特定的例子中它们是最优的。