[cfe-dev] Clang SA false positive

Daniel Marjamäki via cfe-dev cfe-dev at lists.llvm.org
Mon Oct 19 06:14:31 PDT 2015


Hello!

In my humble opinion that is a genuine false positive.

Unless we can see that printInt modifies zero, we should not write a warning. I would assume that external functions are "well behaved".


Ø  Why? Because even though it is static and printInt should not be able to modify it, printInt might be able to call into another function which can modify the value of zero.

Then the translation unit would have to for instance have a globally accessible function that modifies zero.

As I see it.. we know that zero is not modified neither directly/indirectly by printInt if the provided code is the entire TU.

Best regards,
Daniel Marjamäki





On 19 October 2015 at 13:13, Bhargava Shastry via cfe-dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>> wrote:
Hi All,

I came across a curious pattern of FPs while evaluating Clang SA:

$ cat garbageread-fp.c
1. extern void printInt(int x); // prints int
2.
3. static int zero = 0;
4.
5. void f() {
6.   int x;
7.   if (zero != 0)
8.        printInt(0); // dead code
9.   else
10.        x = 0;
11.  if (zero == 0) {
12.        if (!x)
13.                printInt(x);
14.   }
15. }

$ clang --analyze garbageread-fp.c
garbageread-fp.c:12:8: warning: Branch condition evaluates to a garbage
value
        if (!x)
            ^~
1 warning generated.

I have uploaded an html report here: http://output.jsbin.com/jiqewevihi

Why does Clang SA forget the constraint down the execution path?

Notes:
1. Replacing static with extern retains the FP.
2. The FP has something to do with function inlining. Replacing printInt
with standard library function makes the FP go away!

Regards,
Bhargava

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151019/4d00db93/attachment.html>


More information about the cfe-dev mailing list