<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Would it make sense to allow this sort of behaviour to be configurable?<div><br></div><div>For example, much of the time I might not want to be nagged with “this may be a problem” and would like a pragmatic approach, but if I’m writing some critical code I would like to know “this cannot be proven to be correct” and would like the check to be pessimistic.</div><div><br></div><div>These different use-cases can also be adopted when checking legacy code (pragmatic) or new code (pessimistic).</div><div><br></div><div>For the pessimistic case, there is still the chance to use information about bar() to drop the warning if it can be shown never to yield a null pointer.<br><br><div id="AppleMailSignature" dir="ltr">Sent from my iPhone</div><div dir="ltr"><br>On 27 Jun 2019, at 22:55, Artem Dergachev via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
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.<br>
<br>
<div class="moz-cite-prefix">On 6/27/19 2:49 PM, Gábor Horváth
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAPRL4a0ZaQZ9H07DWmEdUjKnRCam2XS3cMsSbZea6SQL_Be85g@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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" moz-do-not-send="true">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>
</blockquote>
<br>
</div></blockquote><blockquote type="cite"><div dir="ltr"><span>_______________________________________________</span><br><span>cfe-dev mailing list</span><br><span><a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a></span><br><span><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a></span><br></div></blockquote></div></body></html>