[cfe-dev] CFG initializers and destructors patch

[Marcin Świderski]

W dniu 3 września 2010 08:51 użytkownik Ted Kremenek
<kremenek at apple.com>napisał:

> On Sep 2, 2010, at 11:25 PM, Marcin Świderski <marcin.sfider at gmail.com>
> wrote:
>
> > If we would want to model destructors of temporaries directly in CFG we
> would have to generate blocks structure mirroring that generated for full
> expression. That is because of expressions with control flow (&&, ||, ?:).
> But what do we need this for?
> > - If we want to know of all destructors that can be called at the and of
> full expression, we can look at CXXExprWithTemporaries in AST.
> > - If we want to know exactly what destructors will be called at the end
> of full expression we can build stack of all temporaries seen on some
> specific path.
> > Direct modeling this in CFG won't be easier to use by a client in any of
> this cases IMO.
>
> I obviously disagree with this last point, but hopefully I can give you a
> good reason of why I think representing these destructors calls in the CFG
> is valuable.
>
> If we don't model them in the CFG, then every client has to potentially
> replicate some of this reasoning, which is messy at best.  Even in vanilla
> C, there are enough edge cases to making reasoning about control-flow
> tricky, especially when you compose language features that have control-flow
> of their own.  In this case, there are control-dependencies between
> destructors calls of temporaries, as well as control dependencies between
> these destructors and other destructors, exception handling edges, etc.  The
> whole point of the CFG is that we get it right in one place and clients
> don't have to think about any special cases.  This is crucial, as it really
> provides a nice decomposition of reasoning between analyses (that just care
> about the properties they are reasoning about) and all the logic to reason
> about control-flow.
>
> Right, if we have destructor that throws (which we shouldn't, but who
knows) we probably want it directly in CFG. I'll think more about this
later, maybe when what is done so far will find it's way to repository.


> Finally, if you don't buy that argument, the other benefit for clients of
> having explicit CFGElements in the CFG for such destructors is that they
> provide convenient handles (i.e., ProgramPoints) to anchor dataflow facts,
> both in the path-sensitive engine and basic flow-sensitive analyses.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20100903/17eef04c/attachment.html>