[cfe-dev] Clang SA false positive
Daniel Marjamäki via cfe-dev
cfe-dev at lists.llvm.org
Mon Oct 19 06:50:00 PDT 2015
Hello!
> Checking whether a globally available function can modify the static variable sounds like a good idea. I think it might worth a patch, to preserve the value in this case.
ok.
as I understand that would eliminate some FP but not all.
when using "well behaved" global functions there will be false positives.
imho whole program analysis is required to write these warnings.
Best regards,
Daniel Marjamäki
..................................................................................................................
Daniel Marjamäki Senior Engineer
Evidente ES East AB Warfvinges väg 34 SE-112 51 Stockholm Sweden
Mobile: +46 (0)709 12 42 62
E-mail: Daniel.Marjamaki at evidente.se
www.evidente.se
________________________________________
Från: Gábor Horváth [xazax.hun at gmail.com]
Skickat: den 19 oktober 2015 15:25
Till: Daniel Marjamäki
Kopia: Clang Dev; Bhargava Shastry
Ämne: Re: Clang SA false positive
2015. okt. 19. du. 3:14 ezt írta ("Daniel Marjamäki" <Daniel.Marjamaki at evidente.se<mailto:Daniel.Marjamaki at evidente.se>>):
>
>
>
> 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.
>
>
Checking whether a globally available function can modify the static variable sounds like a good idea. I think it might worth a patch, to preserve the value in this case.
>
> 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
>
More information about the cfe-dev
mailing list