<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
We do occasionally make things configurable but this particular
situation strikes me as something that i'd find hard to explain to
the users if i add such option. I guess we can eventually add a
global "optimism level" option that would tweak a lot of such
behaviors.<br>
<br>
But even when we do that, we'll be pretty far away from a
verification machine. Even in the most optimistic mode we won't give
any guarantees that we'll prevent all the bugs of the given kind, so
for a seriously critical piece of code you'll have to use other
tools.<br>
<br>
<div class="moz-cite-prefix">On 6/27/19 3:13 PM, Phil King wrote:<br>
</div>
<blockquote type="cite"
cite="mid:82407DBB-B708-4706-AC44-901885C5D94C@rocketmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
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" moz-do-not-send="true">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"
moz-do-not-send="true">cfe-dev@lists.llvm.org</a></span><br>
<span><a
href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev"
moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a></span><br>
</div>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>