<div dir="ltr">I am not sure I follow why do we think that the second example is a false positive. <br><div>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. <br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 27 Jun 2019 at 13:56, Artem Dergachev <<a href="mailto:noqnoqneo@gmail.com">noqnoqneo@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This is very loosely related to Kristof's GSoC and this is my favorite <br>
subject: weird assumption chains.<br>
<br>
Consider:<br>
<br>
   void foo1() {<br>
     int *a = bar();<br>
     int *b = a;<br>
     if (b) { /* ... */ }<br>
     *a = 1;<br>
   }<br>
<br>
This is a valid null dereference bug. Like, 'b' is probably null <br>
(otherwise why check?), therefore 'a', which is equal to 'b', may also <br>
be null.<br>
<br>
Now consider:<br>
<br>
   void foo2() {<br>
     int *a = bar();<br>
     int *b = nullptr;<br>
     if (coin()) {<br>
       b = a;<br>
     }<br>
     if (b) { /* ... */ }<br>
     *a = 1;<br>
   }<br>
<br>
In foo2 we will report a null dereference as well, however the null <br>
check for 'b' is well-justified even if bar() never returns null, <br>
therefore it's a false positive.<br>
<br>
How 'bout we suppress the null dereference warning when the <br>
reaching-definition analysis for 'b' that starts at 'if (b)' - i.e. at <br>
the collapse point - yields multiple definitions and some of them is a <br>
plain null?<br>
<br>
Note that the plain-null definition would never be a part of the bug <br>
path because it would not have a corresponding collapse point (it's <br>
already a concrete null).<br>
</blockquote></div></div>