Clang Analyzer误报或溢出?

时间:2013-05-01 00:35:16

标签: c enums switch-statement clang-static-analyzer

下面是我们的一些代码的简化,似乎它演示了clang分析器中的一个错误,尽管我们的代码中可能存在真正的错误。

typedef enum {
    value1 =  0x8000, /*If value1 is initialized at < 0x8000,
                        the bug doesn't occur*/
    value2,
    value3,
    value4,
    value5,
    value6
}myEnum;

static bool test_UTIL(bool aBool, UINT16 iCaseValue)
{
    bool canMatch = true;
    int myValue; /*not initialized*/

    if (aBool)
        myValue = 1;  /*initialized */
    else
        canMatch = ((value1 == iCaseValue)
             || (value2 == iCaseValue)
             || (value3 == iCaseValue)
             || (value4 == iCaseValue)
             || (value5 == iCaseValue)
             || (value6 == iCaseValue));

    if (canMatch)
    {
        switch (iCaseValue) 
        {
            case value1:
            case value2:
            case value3:
            case value4:
            case value5:
            case value6:
                break;

            default:
                /*This triggers a clang warning, claiming myValue is undefined*/
            canMatch = (iCaseValue == myValue);
            break;
        }
    }

    return canMatch;
}

如注释中所述,只有在枚举开始于0x8000的范围内时才会发生错误,如果它不是无符号的,则为符号位。我们是否有可能以某种方式在switch语句中隐式地转换为带符号的16位整数?还是Clang很困惑?

当然,这个例子可能会被重构以实现相同的行为,但是这是基于20岁以上的代码,为了满足错误的分析器警告而不值得重写。

编辑:我已添加下面test_UTIL()函数生成的程序集。虽然其他人可能对它感兴趣,但我无法阅读装配以发现问题:

_test_UTIL:                             ## @test_UTIL
Ltmp15:
    .cfi_startproc
Lfunc_begin1:
    .loc    1 24 0                  ## /Users/jbrooks/Desktop/test/test/main.c:24:0
## BB#0:
    pushq   %rbp
Ltmp16:
    .cfi_def_cfa_offset 16
Ltmp17:
    .cfi_offset %rbp, -16
    movq    %rsp, %rbp
Ltmp18:
    .cfi_def_cfa_register %rbp
    movw    %si, %ax
    movl    %edi, -4(%rbp)
    movw    %ax, -6(%rbp)
    .loc    1 25 22 prologue_end    ## /Users/jbrooks/Desktop/test/test/main.c:25:22
Ltmp19:
    movl    $1, -12(%rbp)
    .loc    1 28 2                  ## /Users/jbrooks/Desktop/test/test/main.c:28:2
    cmpl    $0, -4(%rbp)
    je  LBB1_2
## BB#1:
    .loc    1 29 3                  ## /Users/jbrooks/Desktop/test/test/main.c:29:3
    movl    $1, -16(%rbp)
    jmp LBB1_9
LBB1_2:
    movb    $1, %al
    movl    $32768, %ecx            ## imm = 0x8000
    .loc    1 31 3                  ## /Users/jbrooks/Desktop/test/test/main.c:31:3
    movzwl  -6(%rbp), %edx
    cmpl    %edx, %ecx
    movb    %al, -17(%rbp)          ## 1-byte Spill
    je  LBB1_8
## BB#3:
    movb    $1, %al
    movl    $32769, %ecx            ## imm = 0x8001
    movzwl  -6(%rbp), %edx
    cmpl    %edx, %ecx
    movb    %al, -17(%rbp)          ## 1-byte Spill
    je  LBB1_8
## BB#4:
    movb    $1, %al
    movl    $32770, %ecx            ## imm = 0x8002
    movzwl  -6(%rbp), %edx
    cmpl    %edx, %ecx
    movb    %al, -17(%rbp)          ## 1-byte Spill
    je  LBB1_8
## BB#5:
    movb    $1, %al
    movl    $32771, %ecx            ## imm = 0x8003
    movzwl  -6(%rbp), %edx
    cmpl    %edx, %ecx
    movb    %al, -17(%rbp)          ## 1-byte Spill
    je  LBB1_8
## BB#6:
    movb    $1, %al
    movl    $32772, %ecx            ## imm = 0x8004
    movzwl  -6(%rbp), %edx
    cmpl    %edx, %ecx
    movb    %al, -17(%rbp)          ## 1-byte Spill
    je  LBB1_8
## BB#7:
    movl    $32773, %eax            ## imm = 0x8005
    movzwl  -6(%rbp), %ecx
    cmpl    %ecx, %eax
    sete    %dl
    movb    %dl, -17(%rbp)          ## 1-byte Spill
LBB1_8:
    movb    -17(%rbp), %al          ## 1-byte Reload
    andb    $1, %al
    movzbl  %al, %ecx
    movl    %ecx, -12(%rbp)
LBB1_9:
    .loc    1 38 2                  ## /Users/jbrooks/Desktop/test/test/main.c:38:2
    cmpl    $0, -12(%rbp)
    je  LBB1_14
## BB#10:
    .loc    1 40 3                  ## /Users/jbrooks/Desktop/test/test/main.c:40:3
Ltmp20:
    movzwl  -6(%rbp), %eax
    leal    -32768(%rax), %eax
    cmpl    $5, %eax
    ja  LBB1_12
    jmp LBB1_11
LBB1_11:
    .loc    1 48 5                  ## /Users/jbrooks/Desktop/test/test/main.c:48:5
Ltmp21:
    jmp LBB1_13
LBB1_12:
    .loc    1 52 5                  ## /Users/jbrooks/Desktop/test/test/main.c:52:5
    movzwl  -6(%rbp), %eax
    cmpl    -16(%rbp), %eax
    sete    %cl
    andb    $1, %cl
    movzbl  %cl, %eax
    movl    %eax, -12(%rbp)
Ltmp22:
LBB1_13:
LBB1_14:
    .loc    1 57 2                  ## /Users/jbrooks/Desktop/test/test/main.c:57:2
    movl    -12(%rbp), %eax
    popq    %rbp
    ret
Ltmp23:
Lfunc_end1:

1 个答案:

答案 0 :(得分:1)

一个未知的是编译器选择用于表示myEnum的基础整数类型。这是“实现定义的”,因为选择需要确定性,以便单独编译的文件可以链接在一起,但在编译器的文档解释如何选择此类型的意义上,它不是实现定义的。选择取决于枚举的定义,任何描述都只能是算法。

无论这个阴影如何,我认为函数是定义的(它不会从未初始化的myValue读取任何参数)。换句话说,警告是误报。我已经使用另一个静态分析器“验证”了这一点,该分析器检测未初始化内存的使用情况。

如何解除“myEnum”影子的“整数类型”,可以发布clang-the-compiler生成的汇编代码。如果汇编代码中存在未初始化的访问权限,则更容易理解原因。


这里可能会发生什么,但像Clang这样功能齐全的静态分析仪是一个复杂的野兽,来自不熟悉其内部结构的人的解释应该带有一丝盐,是基础整数当为myEnum选择0x8000而不是较小的值时,为value1选择的类型是不同的。对于较小的值,myEnum的基础类型可以是带符号的16位short int,而0x8000则强制编译器使用unsigned short intmyEnum的这种不同类型会在表示函数的抽象语法树中引入更多隐式转换,从而使其更难预测并导致误报。我不对Clang工作,但我可以向你保证,这些隐式转换在C的静态分析器中总是很难处理。


Clang开发人员会考虑误报错误,他们当然希望听到这个错误。 homepage说:

  

请通过举报误报来帮助我们做这项工作

这句话直接链接到如何提交错误的解释。