[cfe-dev] CFG initializers and destructors patch

[Ted Kremenek]

On Sep 5, 2010, at 9:57 PM, Ted Kremenek <kremenek at apple.com> wrote:

> 
> On Sep 5, 2010, at 8:37 PM, Zhongxing Xu wrote:
> 
>> About CFGElement, I think we an avoid using two pointers in it. Currently the second pointer data is used for 'the statement that triggers the dtor. I think we don't need a pointer for it. The position where the CFGElement resides is the place where it is triggered. It is not triggered by a statement. 
> 
> One thing to keep in mind is that we will want the ability to distinguish different CFGImplicitDtor's that represent the destruction of the same object (at different locations).  This will be need for creating ProgramPoints, both for the flow-sensitive and path-sensitive engines, that we can use as points to anchor dataflow facts at unique locations.  With Stmt's, for the most part a single Stmt* appears once in a CFG (thus creating unique ProgramPoints).  That isn't the case for destructors of the same object.  This means we will likely need a second field in CFGElement that has some data that uniquely distingues them.  If that is the call location, then that might be unique enough.

(responding to my own comment)

One thing we could do for ProgramPoints is have them point to the CFGElement itself (e.g., CFGImplicitDtor*), and use that pointer address to be the unique identifier (instead of trying to have the contents of CFGElements uniquely distinguish them).  We wouldn't need to do this for all CFGElements (e.g., ones that wrap Stmt*); just the ones we can't uniquely distinguish by their contents alone.  Doing this would allow us to optimize away the second pointer as Zhongxing suggested.

That said, keeping the second pointer doesn't sound so bad to me for now, as we may find it to be useful.  Diagnostics, however, will want to know where the destructor occurred, so I'm happy as long as we have a way to reconstruct this information.