[cfe-dev] [analyzer][GSoC] Problem Statement: Improving BugReporter with static backward program slicing

[Kristóf Umann via cfe-dev]

> 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.
>
> 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.

I guess it depends on what we want to do.

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 *conditional* slicing with the constraints the
analyzer gathered, should we chose to go with an ExplodedGraph based
algorithm.

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.

> 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.

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.


On Thu, 4 Apr 2019 at 01:06, Artem Dergachev <noqnoqneo at gmail.com> wrote:

> I mean, assigning 3 to 'n' :)
>
> On 4/3/19 4:05 PM, Artem Dergachev wrote:
>
> *Assigning 'n' to '3'*
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190404/f9fc9494/attachment.html>