Static analyzer: dead store false positives

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;
}

The Clang static analyzer flags the last line as having dead stores: "Value stored to 'a' is never read", "Value stored to 'b' is never read", etc.

Is there some way to deal with this false positive? I don't think there's any way to rewrite the code in a way that makes Clang happy, but perhaps there's a source code annotation that tells the analyzer to skip this line (or the entire function). Unfortunately I couldn't find anything here:

http://clang-analyzer.llvm.org/annotations.html

Thanks,

Trevor

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.

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.

Chris

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.