[cfe-dev] [analyzer] Speaking about reaching definitions...

[Artem Dergachev via cfe-dev]

Yeah, i mean, we cannot be sure, therefore we want to be conservative 
and not bother the user with a warning. It might be a true positive, but 
it's very wonky and there's nothing in the code that indicates that 
bar() may return null; the code makes perfect sense even if bar() 
doesn't ever return null.

On 6/27/19 2:49 PM, Gábor Horváth wrote:
> I am not sure I follow why do we think that the second example is a 
> false positive.
> I think it depends on the user intent. If the user wanted to check if 
> b was reassigned (i.e. checking for the source of the value), and bar 
> never returns a null pointer than it is definitely a false positive. 
> But we cannot be sure what the intent of the check was. What if the 
> user just wanted to check the value regardless of its source.
>
> On Thu, 27 Jun 2019 at 13:56, Artem Dergachev <noqnoqneo at gmail.com 
> <mailto:noqnoqneo at gmail.com>> wrote:
>
>     This is very loosely related to Kristof's GSoC and this is my
>     favorite
>     subject: weird assumption chains.
>
>     Consider:
>
>        void foo1() {
>          int *a = bar();
>          int *b = a;
>          if (b) { /* ... */ }
>          *a = 1;
>        }
>
>     This is a valid null dereference bug. Like, 'b' is probably null
>     (otherwise why check?), therefore 'a', which is equal to 'b', may
>     also
>     be null.
>
>     Now consider:
>
>        void foo2() {
>          int *a = bar();
>          int *b = nullptr;
>          if (coin()) {
>            b = a;
>          }
>          if (b) { /* ... */ }
>          *a = 1;
>        }
>
>     In foo2 we will report a null dereference as well, however the null
>     check for 'b' is well-justified even if bar() never returns null,
>     therefore it's a false positive.
>
>     How 'bout we suppress the null dereference warning when the
>     reaching-definition analysis for 'b' that starts at 'if (b)' -
>     i.e. at
>     the collapse point - yields multiple definitions and some of them
>     is a
>     plain null?
>
>     Note that the plain-null definition would never be a part of the bug
>     path because it would not have a corresponding collapse point (it's
>     already a concrete null).
>

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