[cfe-dev] Static analyzer: dead store false positives

[Ted Kremenek]

On Mar 15, 2011, at 10:52 AM, Christopher Jefferson wrote:

> 
> On 15 Mar 2011, at 17:48, Trevor Harmon wrote:
> 
>> My app includes a third-party SHA-1 implementation that does some local variable wiping, I assume for security reasons. It looks like this:
>> 
>> void SHA1Transform(...) {
>>   u_int32_t a, b, c, d, e;
>>   ....
>>   /* Wipe variables */
>>   a = b = c = d = e = 0;
>> }
> 
> Unless you compiler this code without optimisation (and even then), it is very likely the compiler will optimise away those wipes and leave the values in memory, or registers, or wherever it feels like.

The compiler does indeed optimize those stores away.  For example:

$ cat t.c
int bar();
void baz();

void foo() {
  int x = bar();
  baz(x);
  x = 0;
}

$ clang -O2 -emit-llvm -S t.c -o -
; ModuleID = 't.c'
target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64"
target triple = "x86_64-apple-darwin10.0.0"

define void @foo() nounwind ssp {
entry:
  %call = tail call i32 (...)* @bar() nounwind
  tail call void (...)* @baz(i32 %call) nounwind
  ret void
}

declare i32 @bar(...)

declare void @baz(...)


As you can see, the store to 'x' doesn't exist.

> If you made the variables volatile there is a better chance you would get the result you want, and I would expect clang wouldn't flag them (at least, it shouldn't). Of course that might also well lead to lower performance.

The analyzer doesn't take volatility into account for this warning, but it easily could.