<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Nice point, indeed this may be of interest. I think it'd be of much
more interest if the Flag was initially initialized to 0. If we fail
to justify that, our warning would still be well-justified, but in
some cases it might be a nice piece of info to add indeded.<br>
<br>
What i was actually trying to say is "hey, our approach is probably
still not entirely perfect, but i've no idea what 'perfect' is and
it shouldn't really be preventing us from trying out your solution;
we don't have anything better anyway" :)<br>
<br>
<div class="moz-cite-prefix">On 5/31/19 2:47 AM, Kristóf Umann
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAGcXOD4g4XDcNJ7eKTzKPoaSaKsyUvzkcvq=kTHOvn4bY2+FRQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr"><br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, 31 May 2019 at
03:12, 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">
<div bgcolor="#FFFFFF"> <br>
<br>
<div class="gmail-m_7841762363038775592moz-cite-prefix">On
5/30/19 6:04 PM, Kristóf Umann wrote:<br>
</div>
<blockquote type="cite">
<div dir="auto">
<div><br>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, 31 May
2019, 02:55 Artem Dergachev, <<a
href="mailto:noqnoqneo@gmail.com"
target="_blank" 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">
<div bgcolor="#FFFFFF"> Interesting.<br>
<br>
Condition on line 12 would not be our control
dependency - neither in example 1 nor in
example 2, simply because there's nothing
interesting within either branches of that
if-statement. The 'new int' assignment would
have been interesting if we solved the
should-not-have-happened problem of "x should
not have been overwritten", but for now we
don't do that.</div>
</blockquote>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">Thats my game plan exactly :)</div>
<div dir="auto">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"><br>
At the same time, condition on line 16 would
still be a control dependency of our report in
both examples, because this is where the
actual crash happens. So we will have a note
on line 05 in both cases, even if it's
completely unnecessary in the second example.<br>
</div>
</blockquote>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">Why would it be? We'd never come
across the nullptr dereference if it wasn't for flag
having its value reset on line 14.</div>
</div>
</blockquote>
<br>
This note is unnecessary because it's not that surprising
that the flag can be true in this case. It simply follows
from the presence of the check: if the flag is always
false, then this if-statement is dead code, which is a bug
on its own.<br>
</div>
</blockquote>
<div><br>
</div>
<div>I somewhat disagree. I think the bug report is clearer
when we argue about why we assume (and do not know) the
value of flag. But I guess we'd really need to see the
impact of this before reasoning about it. I don't
immediately see any major roadblocks that would prevent me
from implementing this as an experiment within an hour or
so, and gather some experience with it.</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"> In example 1 the real thing that's
worth conveying is that the value of the flag changes
between line 12 and line 16 (and also between line 10 and
line 12). </div>
</blockquote>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"> <br>
But i don't see an immediate way to formalize this kind of
reasoning.<br>
</div>
</blockquote>
<div><br>
</div>
<div>I hope it'll work out with the combined solution to the
"must-have-happened" and "should-not-have-happened" cases,
but it's hard to foresee it this early on.</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<blockquote type="cite">
<div dir="auto">
<div dir="auto">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"><br>
We would indeed never have a note on line 10.
This is, in fact, a dead store, this value is
never used, so we wouldn't be able to track
anything back to it.<br>
</div>
</blockquote>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">I messed up the numbering, I did in
fact mean 11 when I wrote 10 :)</div>
<div dir="auto">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"><br>
<div
class="gmail-m_7841762363038775592m_-4130761129068717718moz-cite-prefix">On
5/30/19 4:48 PM, Kristóf Umann wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>Allow me to elaborate.</div>
<div><span><br>
</span></div>
<div><span><b><font size="4">Example 1.:</font></b></span></div>
<div>
<p dir="ltr"
style="font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:"Courier New";color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">01 int flag;</span></p>
<p dir="ltr"
style="font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:"Courier New";color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">02 bool coin();</span></p>
<p dir="ltr"
style="font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:"Courier New";color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">03 </span></p>
<p dir="ltr"
style="font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:"Courier New";color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">04 void foo() {</span></p>
<p dir="ltr"
style="font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:"Courier New";color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">05 flag = coin(); // no note</span></p>
<p dir="ltr"
style="font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:"Courier New";color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">06 }</span></p>
<p dir="ltr"
style="font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:"Courier New";color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">07 </span></p>
<p dir="ltr"
style="font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:"Courier New";color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">08 int main() {</span></p>
<p dir="ltr"
style="font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:"Courier New";color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">09 int *x = 0; // x initialized to 0</span></p>
<p dir="ltr"
style="font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:"Courier New";color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">10 flag = 1;</span></p>
<p dir="ltr"
style="font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:"Courier New";color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">11 foo();</span></p>
<p dir="ltr"
style="font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:"Courier New";color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">12 if (flag) // assumed false</span></p>
<p dir="ltr"
style="font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:"Courier New";color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">13 x = new int;</span></p>
<p dir="ltr"
style="font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:"Courier New";color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">14 foo();</span></p>
<p dir="ltr"
style="font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:"Courier New";color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">15 </span></p>
<p dir="ltr"
style="font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:"Courier New";color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">16 if (flag) // assumed true</span></p>
<p dir="ltr"
style="font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:"Courier New";color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">17 *x = 5; // warn</span></p>
<p dir="ltr"
style="font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:"Courier New";color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">18 }</span></p>
</div>
<div><span><br>
</span></div>
<div><span><b><font size="4">Example 2.:
(note the change on line 15)</font></b></span></div>
<div>
<p dir="ltr"
style="font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:"Courier New";color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">01 int flag;</span></p>
<p dir="ltr"
style="font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:"Courier New";color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">02 bool coin();</span></p>
<p dir="ltr"
style="font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:"Courier New";color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">03 </span></p>
<p dir="ltr"
style="font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:"Courier New";color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">04 void foo() {</span></p>
<p dir="ltr"
style="font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:"Courier New";color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">05 flag = coin(); // no note</span></p>
<p dir="ltr"
style="font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:"Courier New";color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">06 }</span></p>
<p dir="ltr"
style="font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:"Courier New";color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">07 </span></p>
<p dir="ltr"
style="font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:"Courier New";color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">08 int main() {</span></p>
<p dir="ltr"
style="font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:"Courier New";color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">09 int *x = 0;</span></p>
<p dir="ltr"
style="font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:"Courier New";color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">10 flag = 1;</span></p>
<p dir="ltr"
style="font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:"Courier New";color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">11 foo();</span></p>
<p dir="ltr"
style="font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:"Courier New";color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">12 if (flag) // assumed false</span></p>
<p dir="ltr"
style="font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:"Courier New";color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">13 x = new int;</span></p>
<p dir="ltr"
style="font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:"Courier New";color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">14 foo();</span></p>
<p dir="ltr"
style="font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:"Courier New";color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">15 x = 0; // x set to 0</span></p>
<p dir="ltr"
style="font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:"Courier New";color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">16 if (flag) // assumed true</span></p>
<p dir="ltr"
style="font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:"Courier New";color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">17 *x = 5; // warn</span></p>
<p dir="ltr"
style="font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:"Courier New";color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">18 }</span></p>
</div>
<div><span
id="gmail-m_7841762363038775592m_-4130761129068717718gmail-docs-internal-guid-4afc448c-7fff-3e2d-c87d-f55781fa8e89">
<div dir="ltr" style="margin-left:0pt"><br>
</div>
<div style="margin-left:0pt">By
tweaking <font face="courier new,
monospace">trackExpressionValue</font>
a bit:</div>
<div dir="ltr" style="margin-left:0pt"><br>
</div>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:"Courier New";color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">bool trackExpressionValue(const ExplodedNode *N,</span></p>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:"Courier New";color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap"> const Stmt *S, BugReport &R,</span></p>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:"Courier New";color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap"> bool IsArg=false,</span></p>
<p dir="ltr"
style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:"Courier New";color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap"> bool EnableNullFPSuppression=true);</span></p>
<br>
<span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">Should a block </span><span style="font-size:11pt;font-family:"Courier New";color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">B</span><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap"> in the bug path be a control dependency of </span><span style="font-size:11pt;font-family:"Courier New";color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">N</span><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">, track the expression value in the condition of </span><span style="font-size:11pt;font-family:"Courier New";color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">B</span><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">. With that, I believe we should get a note for statement 14. For statement 10, we still wouldn’t get a note saying that flag’s value was invalidated (I fear), but it’s more of a should-not-have-happened case. For Example 2 however, we’d get a pretty much perfect bug report.</span></span><br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On
Fri, 31 May 2019 at 00:16, Kristóf
Umann <<a
href="mailto:dkszelethus@gmail.com"
rel="noreferrer" target="_blank"
moz-do-not-send="true">dkszelethus@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">
<div dir="ltr">
<div dir="ltr"><br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On
Mon, 27 May 2019 at 19:48, Artem
Dergachev <<a
href="mailto:noqnoqneo@gmail.com"
rel="noreferrer"
target="_blank"
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"><br>
<br>
On 5/27/19 10:12 AM, Gábor
Horváth wrote:<br>
> Hi!<br>
><br>
> I wanted to share some of
my points as well but had little
time to do so.<br>
><br>
> Artem identified two kinds
of issues. One of which has all
the <br>
> information available in
the bug path (in his
terminology: <br>
> must-have-happened) and the
other which has not ( <br>
> should-not-have-happened).
The goal is the same in both of
the cases, <br>
> identify all dependencies
including control and data
dependencies. The <br>
> main difference is that in
one case we could use all the
information <br>
> available in the bug path
while in the other we cannot.<br>
><br>
> 1. must-have-happened:<br>
> Since the bug-path contains
all the information we need, I
do agree <br>
> with Artem using bug path
visitors might be sufficient. I
do not know <br>
> how reliable
`trackExpressionValue` is in
identifying data <br>
> dependencies, but revising
it could be one step in GSoC.
For example, <br>
> after quickly skimming
through the implementation I am
not sure if it <br>
> is able to track the source
of a constant value that was
constant <br>
> folded during the symbolic
execution from different values.<br>
<br>
It should be able to, because
that's how inlined defensive
check <br>
suppressions work.<br>
</blockquote>
<div><br>
</div>
<div>I recently finished (not yet
published) my work on
implementing control
dependencies for clang's CFG via
LLVM's <font face="courier new,
monospace">IDFCalculator</font>.
Theoretically speaking, by
simply tracking the variables in
the block that is a control
dependency of the block that is
being tracked, we should be able
to get a proper bug report for
Example 1? From afar, it seems
reasonable.</div>
<div> </div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
> Only if we had a way to
test this functionality in
isolation quickly <br>
> :) I think making that
possible would also be a
valuable addition.<br>
><br>
> For control dependencies,
it is great that LLVM already
has some <br>
> algorithms to calculate
dominator sets and it might be
possible to <br>
> make that work for the
Clang CFG.<br>
><br>
> In my opinion, if you only
tackle these problems by the end
of the <br>
> summer your project already
brought great value to the
community.<br>
><br>
> 2. should-not-have-happened<br>
> This category cannot be
solved only using visitors for
sure. So we <br>
> might end up with an
implementation for this problem
that is <br>
> completely separate from
the previous one (maybe except
for getting <br>
> control dependencies?). As
Artem pointed out, we might
query some <br>
> information from the
analyzer e.g. which functions
were inlined. One <br>
> option is to use a slicing
algorithm here. However, we
should make <br>
> sure that the way a
function is conservatively
evaluated by the <br>
> slicing algorithm and the
analyzer is compatible. E.g.: if
the <br>
> analyzer does not
invalidate a memory region
during evaluating the <br>
> call, the statement should
not be considered as relevant
for the <br>
> variable in question. We
have several challenges here,
the analyzer <br>
> reasons about memory
regions while the slicing
algorithm will probably <br>
> not. Also, we need to do
something with pointers, since
we do not want <br>
> to implement a full-fledged
pointer analysis. We also need
to decide <br>
> how to represent arrays,
structures etc.<br>
><br>
> I skimmed through the
algorithm in the google docs,
and I think there <br>
> are some other details we
need to work out. For example,
you never <br>
> remove anything from the
set of relevant variables.
Consider the <br>
> following example:<br>
> x = 5;<br>
> y = x + 2;<br>
> y = 2;<br>
> z = y + 3;<br>
><br>
> Whit the slicing criterion
(z = y + 3). Here, once y is
overwritten <br>
> with 2, it is no longer
relevant, sox should not end up
in the slice. <br>
> The algorithm you proposed
will not handle this correctly
(yet). Also <br>
> I am not sure if we
actually need
therelevant_variable_map or
having a <br>
> set will be sufficient.<br>
><br>
> Regards,<br>
> Gabor<br>
><br>
> On Mon, 27 May 2019 at
12:52, Kristóf Umann <<a
href="mailto:dkszelethus@gmail.com"
rel="noreferrer"
target="_blank"
moz-do-not-send="true">dkszelethus@gmail.com</a>
<br>
> <mailto:<a
href="mailto:dkszelethus@gmail.com"
rel="noreferrer"
target="_blank"
moz-do-not-send="true">dkszelethus@gmail.com</a>>>
wrote:<br>
><br>
> + Ádám Balogh<br>
><br>
> On Fri, 24 May 2019 at
23:31, Artem Dergachev <<a
href="mailto:noqnoqneo@gmail.com"
rel="noreferrer"
target="_blank"
moz-do-not-send="true">noqnoqneo@gmail.com</a><br>
> <mailto:<a
href="mailto:noqnoqneo@gmail.com"
rel="noreferrer"
target="_blank"
moz-do-not-send="true">noqnoqneo@gmail.com</a>>>
wrote:<br>
><br>
> Ok, i think i have
a little bit of clarity.<br>
><br>
> Let's first talk
about must-have-happened
problems. For instance,<br>
><br>
> int *foo() {<br>
> return coin()
? new int : nullptr; // needs
note<br>
> }<br>
> void bar() {<br>
> int *x = foo();<br>
> *x = 1; //
warning: null dereference<br>
> }<br>
><br>
> In this case
trackExpressionValue solves the<br>
>
"must-have-happened" problem of
"x must-have been assigned a<br>
> null pointer value"
by displaying a note when foo()
returns<br>
> nullptr. This
currently more or less works
correctly - there<br>
> are a lot of bugs
but the overall idea behind<br>
>
trackExpressionValue is
correct.<br>
><br>
> Example 1 in your
document is another example of a<br>
> must-have-happened
problem: in order for the report
to be<br>
> valid, we need to
show that 'flag'
must-have-changed between<br>
> line 17 and line
13. That's something that the
Static Analyzer<br>
> currently cannot
handle and you plan to improve
upon it.<br>
><br>
> Hʏᴘᴏᴛʜᴇsɪs1. All
"must-have-happened" problems
should be<br>
> solved with a bug
visitor. We don't need any new
analysis<br>
> algorithm for that.<br>
><br>
> In particular, i
believe that Example 1 can be
solved by<br>
> extending
trackExpressionValue() with a
bug visitor that<br>
> detects
control-flow-dependencies via
this approach of yours:<br>
><br>
> > "Check whether
the statement is a control
dependency of<br>
> Statement 18 with
dominator sets: 18 doesn't post
dominate 17,<br>
> but every statement
in between them does, meaning
that 17 is a<br>
> control dependency
of 18."<br>
><br>
> I.e., while
ascending through ExplodedGraph,
we pick<br>
> interesting
statements and perform this
domination check on<br>
> their predecessor
nodes until we reach the control
dependency,<br>
> then we track the
control dependency recursively
by adding<br>
> more visitors.<br>
><br>
> I think this is the
first thing we should try on our
GSoC.<br>
><br>
> The reason why i
believe that Hypothesis 1 is
true is that all<br>
> the information
that we need is fully contained
in the bug<br>
> path. If something
must have happened on the path,
then it's<br>
> probably in the
path and we can figure it out by
looking at<br>
> the path. If
something must have happened on
the path and it's<br>
> not in the path,
then why did we emit a warning
in the first<br>
> place?<br>
><br>
> ==============<br>
><br>
> Now, to
should-not-have-happened
problems. The main motivating<br>
> example is:<br>
><br>
> void foo(int *y)
{<br>
> if (coin())
// needs note<br>
> *y = 1;<br>
> }<br>
> void bar() {<br>
> int x;<br>
> foo(&x);<br>
> use(x); //
warning: use of uninitialized
value<br>
> }<br>
><br>
> In order to make
the warning comprehensible, we
have to<br>
> explain to the user
why do we think that 'x' is
uninitialized,<br>
> as it clearly
"should-not-have-been"
initialized for the<br>
> warning to be
correct. For that purpose it is
absolutely<br>
> essential to
display the execution path
within the inlined<br>
> call to foo().<br>
><br>
> One way to achieve
that would be to display *all*
execution<br>
> path and leave it
up to the user to see that the
event that<br>
>
should-not-have-happened has
indeed never happened.<br>
><br>
> That, however,
would be overwhelming, so we use
"path pruning"<br>
> that cuts away
execution paths in inlined calls
that are known<br>
> to have no
interesting events happening.
Which, in turn, makes<br>
> us incapable of
solving should-not-have-happened
problems, as<br>
> it's the whole
point of the problem to display
execution path<br>
> in inlined
functions in which nothing has
happened.<br>
><br>
> In order to figure
this out, we need to learn how
to<br>
> discriminate
between inlined calls in which
nothing<br>
> interesting *could*
have happened in the first place
and<br>
> inlined calls in
which something interesting
could have<br>
> happened but
*didn't*.<br>
><br>
> NoStoreFuncVisitor
solves this problem for the
example above.<br>
> The visitor notices
that the local variable is
passed by<br>
> non-const pointer
into the inlined call and the
call<br>
> syntactically
contains assignments through
this pointer,<br>
> therefore this call
*could* have initialized the
value. The<br>
> visitor then
suppresses pruning of this call
by emitting an<br>
> interesting note
within the call ("returning
without<br>
> initializing
'*y'"...).<br>
><br>
> However, AST-based
analysis in NoStoreFuncVisitor
is very<br>
> primitive and easy
to trick. A more sophisticated
analysis is<br>
> clearly necessary.<br>
><br>
> The second thing we
can try in our GSoC is to come
up with a<br>
> better analysis
specifically for the
uninitialized value<br>
> checker, because we
already have a place to stick it
into and<br>
> we know how exactly
do we want to consume the result
of such<br>
> analysis and
evaluate it.<br>
><br>
> The third thing we
can try in our GSoC is to come
up with more<br>
> such analysis for
other checkers and other<br>
>
should-have-happened problems
and see if a reusable framework<br>
> for creating such
analyses can be implemented.<br>
><br>
><br>
> On 5/23/19 1:25 PM,
Kristóf Umann wrote:<br>
>><br>
>><br>
>> On Thu, 23 May
2019 at 21:58, Kristóf Umann<br>
>> <<a
href="mailto:dkszelethus@gmail.com"
rel="noreferrer"
target="_blank"
moz-do-not-send="true">dkszelethus@gmail.com</a>
<mailto:<a
href="mailto:dkszelethus@gmail.com"
rel="noreferrer"
target="_blank"
moz-do-not-send="true">dkszelethus@gmail.com</a>>>
wrote:<br>
>><br>
>> Please let
me know if I didn't address
something you<br>
>> mentioned!<br>
>><br>
>> On Thu, 23
May 2019 at 02:29, Artem
Dergachev<br>
>> <<a
href="mailto:noqnoqneo@gmail.com"
rel="noreferrer"
target="_blank"
moz-do-not-send="true">noqnoqneo@gmail.com</a>
<mailto:<a
href="mailto:noqnoqneo@gmail.com"
rel="noreferrer"
target="_blank"
moz-do-not-send="true">noqnoqneo@gmail.com</a>>>
wrote:<br>
>><br>
>> My
primary question is, how do you
plan to use the<br>
>> data
that you obtain via your
analysis?<br>
>><br>
>><br>
>> Gather
relevant statements. Keep
ExplodedNodes in the<br>
>> bugpath for
which
PathDiagnosticLocation::getStmt()
is in<br>
>> the set
(or, something like that at
least). But honestly,<br>
>> I didn't
think too much about that yet
:^) I guess we<br>
>> could just
gather ExplodedNodes rather than
statements,<br>
>> we'll see.<br>
>><br>
>> Like,
do you plan to backtrack the
value of all<br>
>>
relevant variables and/or
expressions in the final<br>
>> bug
report that were also
encountered along the bug<br>
>> path?
If yes, then is it possible that
the slicing<br>
>>
criterion gets updated in the
process and you'll have<br>
>> to
re-run the CFG-based analysis to
take it into account?<br>
>><br>
>><br>
>> No, the
slicing criterion is what it is,
and will not<br>
>> change. The
set of relevant statements to
the slicing<br>
>> criterion
define the actual program slice,
which is<br>
>> basically
the thing we're going for in
this project. When<br>
>> it turns
out that a value of a variable
directly affects<br>
>> a variable
in the slicing criterion (either
through data<br>
>> or control
dependency), we just add it to
the set of<br>
>> relevant
variables, and then if something
in the set of<br>
>> relevant
variables is affected (some
statements or<br>
>> variables
turn out to be a control/data
dependencies to<br>
>> them), then
it's added to the respective
relevancy sets.<br>
>> Should we
only traverse the basic blocks
the analyzer<br>
>> visited, I
think we can pull off the
slicing with a<br>
>> single
pass.<br>
>><br>
>><br>
>> We'll see about
that single pass thing though.
I'm gathering<br>
>> some tricky
examples in the document I
shared and working on<br>
>> a neat
algorithm.<br>
>><br>
>> >
What would also be really great
is to assist this<br>
>>
traversal with the information
the analyzer already<br>
>> has,
essentially only inspecting
basic blocks the<br>
>>
analyzer actually visits.<br>
>><br>
>> You
mean visits on the current bug
path or visits on<br>
>> the
equivalence class of bugs or
visits in general<br>
>> during
analysis?<br>
>><br>
>>
Regardless, for many problems
ideally we should<br>
>>
traverse basic blocks that the
analyzer *didn't*<br>
>> visit
(eg., if the function didn't
initialize the<br>
>>
variable on the current path,
we're interested in<br>
>> parts
of the code in which it *did*
initialize the<br>
>>
variable, even though we didn't
necessarily have time<br>
>> to
visit them).<br>
>><br>
>><br>
>> Well I mean
slicing by definition isn't
intended to do<br>
>> that. The
entire point of it is to gather
the smallest<br>
>> slice
related to the slicing
criterion, and my project<br>
>> aims to
fill in the gaps where we don't
provide enough<br>
>>
information.<br>
>><br>
>> It
actually sounds as if all
problems that we're<br>
>> trying
to solve here can be classified
into<br>
>>
"must-have-happened" problems
(eg., "variable<br>
>>
must-have been declared without
initialization",<br>
>>
"variable must-have been set to
nullptr", "memory<br>
>>
must-have been allocated") and<br>
>>
"should-not-have-happened"
problems (eg., "variable<br>
>>
should-not-have been
initialized", "null value<br>
>>
should-not-have been
overwritten", "pointer<br>
>>
should-not-have escaped").<br>
>><br>
>> For
must-have-happened problems, i'm
recently under<br>
>> an
impression that we should
suppress the bug report<br>
>>
entirely when we fail to solve
them (i.e., if fail to<br>
>> explain
to the user where exactly does
this happen,<br>
>> then
the report is impossible to
understand anyway).<br>
>> This is
currently a very big problem for
our null<br>
>>
dereference checker on some
codebases, especially<br>
>> because
it uses this tracking for
suppressions as<br>
>> well
(aka inlined defensive checks),
so when it fails<br>
>> to
track the variable it's likely a
legit false<br>
>>
positive as well, not simply a
hard-to-understand report.<br>
>><br>
>><br>
>> I think
this set calculating approach
inherently gathers<br>
>> far more
information, allowing us to make
better<br>
>> judgement
on whether we should suppress
the report.<br>
>><br>
>> For
should-not-have-happened
problems i'm much more<br>
>>
confused. We're talking about
looking for places<br>
>> where
it *could* have happened and
then trying to<br>
>> explain
to the user why none of them
have actually<br>
>>
happened. I'm not sure what are
the consequences of<br>
>> failing
to explain to the user why
didn't a<br>
>>
particular piece of code do
something, because i've<br>
>> no idea
how do users intuitively figure
out which<br>
>> code
*could* have done these things
and which clearly<br>
>>
couldn't.<br>
>><br>
>><br>
>> Im really
at a loss here :) Can you
provide some example<br>
>> as to what
a problematic
"must-have-happened" bug report<br>
>> would look
like, and how would you like to
see it<br>
>> improved?
Same for
"should-not-have-happened".
Because as<br>
>> I
understand it, and I might be
wrong, you have problems<br>
>> with this:<br>
>><br>
>> int a; //
declaring a without initializing<br>
>><br>
>> if (rand())
// assuming that the condition
is false<br>
>> a = 5;<br>
>><br>
>> print(a);
// a is undef<br>
>><br>
>> And prefer
to see this:<br>
>><br>
>> int a; //
declaring a without initializing<br>
>><br>
>> if (rand())
// should this condition be
false, a's value<br>
>> will be
indeterministic<br>
>> a = 5; //
writing to a skipped<br>
>><br>
>> print(a);
// a is undef<br>
>><br>
>> and I just
don't see how this would be
possible with<br>
>> slicing at
all. Also, I can't see how this
would scale to<br>
>> real-world
production code.<br>
>><br>
>><br>
>> On
5/22/19 4:11 PM, Kristóf Umann
wrote:<br>
>>><br>
>>> Hi!<br>
>>><br>
>>><br>
>>> I'd
like to share some thoughts
about my GSoC<br>
>>>
project, "Enhancing bug
reporting with static<br>
>>>
backward program slicing"[1].<br>
>>><br>
>>><br>
>>> My
proposal is very specific about
whatI'm aiming to<br>
>>>
improve on, but vague on the
howpart of it. This<br>
>>>
mail aims to add clarify some
of this.<br>
>>><br>
>>><br>
>>>
Program slicing is essentially
a technique of<br>
>>>
discovering data and control
dependencies to the<br>
>>>
slicing criterion, which is a
(statement, {set of<br>
>>>
variables}) pair. Fortunately,
tools for control<br>
>>>
dependencies, namely, dominator
set calculations are<br>
>>>
already implemented, but seems
to be unstable with<br>
>>>
clang's CFG. It would be a
great tool if I were able<br>
>>> to
fix it.<br>
>>><br>
>>><br>
>>>
While my proposal states that I
plan to implement an<br>
>>>
AST-based solution, I'm
actually not sure that this<br>
>>> is
the optimal approach. We could
instead inspect<br>
>>> CFG
blocks in a backwards manner
(coupled with the<br>
>>>
analyzer's call stack), and
gather relevant variable<br>
>>> in
the meanwhile.<br>
>>><br>
>>><br>
>>>
What would also be really great
is to assist this<br>
>>>
traversal with the information
the analyzer already<br>
>>>
has, essentially only
inspecting basic blocks the<br>
>>>
analyzer actually visits.<br>
>>><br>
>>><br>
>>>
Here’s my idea for an algorithm
(from the point of<br>
>>> the
slicing criterion already being
constructed):<br>
>>><br>
>>> <a
href="https://docs.google.com/document/d/1Lx867o3meyQsj0WKOSWMdosSBdw2MUq1aIxyPJM6iLU/edit?usp=sharing"
rel="noreferrer noreferrer"
target="_blank"
moz-do-not-send="true">https://docs.google.com/document/d/1Lx867o3meyQsj0WKOSWMdosSBdw2MUq1aIxyPJM6iLU/edit?usp=sharing</a><br>
>>><br>
>>><br>
>>><br>
>>>
Please note that this is a
veeery rough sketch, I<br>
>>>
didn't think about every edge
case that exists, but<br>
>>> I
think it's an okay start.<br>
>>><br>
>>><br>
>>> [1]<br>
>>> <a
href="https://docs.google.com/document/d/1ci1BCAKojPlqIxIw1J_K2dnATA3z01PuwR_vHJS55TI/edit"
rel="noreferrer noreferrer"
target="_blank"
moz-do-not-send="true">https://docs.google.com/document/d/1ci1BCAKojPlqIxIw1J_K2dnATA3z01PuwR_vHJS55TI/edit</a><br>
>>><br>
>><br>
><br>
<br>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
</body>
</html>