<div dir="ltr"><div>> Instead we can also have a look at the execution path on the ExplodedGraph that goes through the true-branch and see if the value remains null when it exits the if-branch. Kristof, you're saying that you plan to do the slicing over the ExplodedGraph - is that what you mean? This could work as long as the other branch is actually *explored* by the analyzer. If it isn't, it'll be almost impossible to detect, and i don't know how often would this happen, but there's a good chance it's going to be much more rare than us having problems with such highlighting right now.<br></div>><br>> We can also come up with a completely separate CFG-based analysis for this purpose. This is probably the most precise thing to do, because the problem is essentially an all-paths problem (which is why loss of coverage in the ExplodedGraph would bite us). I cannot estimate how difficult such analysis would be to implement (probably pretty scary), but i think Kristof wasn't looking in this direction.<br><br>I guess it depends on what we want to do.<div><br><div>Static slicing isn't defined for the ExplodedGraph, I'll have show that we can transform an ExplodedGraph into a CFG, or define the algorithm on it. From afar, it's very hard to tell how difficult this would be. When looking for a long-term solution, I think it would be better to find an approach where we won't have to worry about whether the analyzer explored everything or not. On the other hand, we could eventually turn this backward static slicing into a backward <i>conditional</i> slicing with the constraints the analyzer gathered, should we chose to go with an ExplodedGraph based algorithm.</div><div><br></div><div>So we'll have to balance these two. Greater accuracy with a chance that the slice will be too big (CFG), or not as accurate but resulting in a smaller slice (ExplodedGraph). I am not yet sure which one I'd like to pursue, but the latter would probably fit our needs better.<br><br>> Id suggest first starting with a syntax-based approach (1) because it sounds to me that the approach that we chose for identifying dependencies on paths that aren't part of the bug path is orthogonal to actually making use of that information to produce notes. Once we learn how to make use of this information, we'll have a taste of this medicine and see if it works. Then we'll see if we need to transition to (2) or (3) depending on such evaluation.<br></div></div><div><br></div><div>I'll be honest, I don't really understand what you mean here. Would you like to see a more down-to-earth syntax-based solution as an exercise "for the big thing"? If so, I'm not sure what you mean specifically.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 4 Apr 2019 at 01:06, 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">
  
    
  
  <div bgcolor="#FFFFFF">
    I mean, assigning 3 to 'n' :)<br>
    <br>
    <div class="gmail-m_7103518053654994422moz-cite-prefix">On 4/3/19 4:05 PM, Artem Dergachev
      wrote:<br>
    </div>
    <blockquote type="cite"><font face="monospace, monospace"><b>Assigning 'n' to '3'</b></font></blockquote>
    <br>
  </div>

</blockquote></div>