[cfe-commits] r105602 - in /cfe/trunk: lib/Checker/CMakeLists.txt lib/Checker/GRExprEngineExperimentalChecks.cpp lib/Checker/GRExprEngineInternalChecks.h lib/Checker/StackAddrLeakChecker.cpp test/Analysis/stackaddrleak.c

[Zhongxing Xu]

>
> +              // The variable is declared in the function scope which we
> are
> +              // leaving. Keeping this variable's address in a global
> variable
> +              // is dangerous.
> +              // FIXME: Currently VarRegion does not carry context
> information.
> +              // So we cannot tell if the local variable instance is in
> the
> +              // current stack frame.
>
>
> I don't think this is true.  I think you can look at the memory space of
> the VarRegion.  Is that not the case?
>
>
>From the memory space region of a VarRegion, we can only know if it's on the
stack or global. We can't know which CallStackFrame it is in. Consider code:

int *p;

void foo(int x) {
  if (x == 1) {
    p = &x;
    foo(2);
  }
}

void bar(void) {
  foo(1);
}

bar calls foo[1], foo calls foo[2]. When we leave the inner most call of
foo[2], the value of 'p' is still valid. We should only emit one warning for
this example. But now we emit two.

$ clang -cc1 -analyze -analyzer-check-objc-mem -analyzer-store region
-analyze-function bar -analyzer-inline-call
-analyzer-experimental-internal-checks stack2.c
stack2.c:6:5: warning: Stack address was saved into a global variable. This
is dangerous because the address will become invalid after returning from
the function.
    foo(2);
    ^~~~~~
stack2.c:4:3: warning: Stack address was saved into a global variable. This
is dangerous because the address will become invalid after returning from
the function.
  if (x == 1) {
  ^
2 warnings generated.

This also explains your questions above. I can't get the LocationContext
from MemRegionVal. I can only get their enclosing DeclContext and match the
DeclContext with the Decl of the LocationContext of the current program
point.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20100609/4d4dd716/attachment.html>