[cfe-dev] CFGElement changes and initializers addition (with patch)

[Ted Kremenek]

On Aug 24, 2010, at 12:23 AM, Marcin Świderski wrote:

> 
> Implicit call to C++ destructor is part of control flow of a program and it should have representation in CFG. However variable going out of scope is not IMO, so I don't think that this would be a good idea. And for C we can jump over variable initialization. So should we create destructor node for 'p' in this case also?:
> 
> void f() {
>   goto label;
>   {
>     int* p = malloc(4);
> label:
>     ...
>   }
>   ...
> }
> 

This is an excellent example.  I don't think we need a destructor CFGElement for 'p'.

> As I understand for delimiter approach we need StartScope and EndScope delimiters to know where in CFG we enter and leave scopes but without jump. In case of jumps it would be for client to deduce what scopes will be left and entered? I mean we don't need any more information in CFG for this?

Scopes are created in well-specified places.  It should be trivial to define a ScopeMap data structure that maps from Stmt* -> scope.  This could be used by GRExprEngine when creating memory regions with a LocationContext that captures the current scope chain.  When we see an access to a region, we can also tell if that region is still valid by consulting the currently active scope chain.  This can all be done lazily.  I see no reason why this needs to be in the CFG.

Destructors, on the other hand, need to be in the CFG because they are sequenced events that take place at specific points in the code.

> 
> If that is the case I understand that that what is to be done is:
> - Adding implicit scopes for selection and iteration statements in case the body is not a compound statement but declares some variables,
> - Not adding EndScope delimiter if scope ends with jump as it would produce unnecessary unreachable CFGBlock.

I think doing this is all overkill, and without a clear benefit over just querying scope information on the side I'm really resistant to seeing this go into the CFG.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20100824/387d4a7f/attachment.html>