下面是我们的一些代码的简化,似乎它演示了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:
答案 0 :(得分:1)
一个未知的是编译器选择用于表示myEnum
的基础整数类型。这是“实现定义的”,因为选择需要确定性,以便单独编译的文件可以链接在一起,但在编译器的文档解释如何选择此类型的意义上,它不是实现定义的。选择取决于枚举的定义,任何描述都只能是算法。
无论这个阴影如何,我认为函数是定义的(它不会从未初始化的myValue
读取任何参数)。换句话说,警告是误报。我已经使用另一个静态分析器“验证”了这一点,该分析器检测未初始化内存的使用情况。
如何解除“myEnum
”影子的“整数类型”,可以发布clang-the-compiler生成的汇编代码。如果汇编代码中存在未初始化的访问权限,则更容易理解原因。
这里可能会发生什么,但像Clang这样功能齐全的静态分析仪是一个复杂的野兽,来自不熟悉其内部结构的人的解释应该带有一丝盐,是基础整数当为myEnum
选择0x8000而不是较小的值时,为value1
选择的类型是不同的。对于较小的值,myEnum
的基础类型可以是带符号的16位short int
,而0x8000则强制编译器使用unsigned short int
。 myEnum
的这种不同类型会在表示函数的抽象语法树中引入更多隐式转换,从而使其更难预测并导致误报。我不对Clang工作,但我可以向你保证,这些隐式转换在C的静态分析器中总是很难处理。
Clang开发人员会考虑误报错误,他们当然希望听到这个错误。 homepage说:
请通过举报误报来帮助我们做这项工作
这句话直接链接到如何提交错误的解释。