[cfe-dev] Reporting a bug found at EndPath at its correct location

[Jordan Rose]

Fair enough. We've done a couple things like this before, the main one being leak reports (which need to report their allocation site). In these cases, we don't save the ExplodedNode for the leak event, but instead walk back up the path to the change of state that corresponds to the allocation site. I'm not sure if I've seen any real alternative strategies.

But there's nothing inherently wrong with doing it your way, other than that you can't clear out your map of ExplodedNodes until the end of analysis (because you don't know all the paths they participate in). There are two caveats I can think of, though:

- Putting ExplodedNodes in the state is a bad idea (because it means two branches will never be able to re-merge), so instead you could store them in a side table on your checker. This is usually discouraged (you'll notice checker callbacks are const) but if you're careful there should be no problem.

- Make sure to generate a new node at the point you want to track, even if you don't have any state to change. The analyzer is allowed to recycle ExplodedNodes that have the same state as their predecessor (plus a few other conditions) unless it was explicitly created by a checker.

I'd see if the "go find the node retroactively" approach works for you before trying the map approach, though.

Does that help?
Jordan


On Sep 17, 2013, at 1:38 , YuvalShahar <yuval.shahar.007 at gmail.com> wrote:

> Sorry for the misunderstanding. It is just a bad choice of example; of course
> I cannot correctly solve the issue of unused variables in a path-sensitive
> check.
> 
> However, the issue I AM trying to solve IS path-sensitive:
> I need to mark many statements in the path and emit my bug reports at end of
> path.
> 
> My questions are about the scheme of creating and saving many ExplodedNodes
> on the state, and then putting the bug reports on the relevant nodes:
> - Would this scheme work?
> - Is it expensive in memory?
> - Is there a preferred scheme?
> 
> Thanks.
> 
> 
> 
> --
> View this message in context: http://clang-developers.42468.n3.nabble.com/Reporting-a-bug-found-at-EndPath-at-its-correct-location-tp4034472p4034506.html
> Sent from the Clang Developers mailing list archive at Nabble.com.
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev