[cfe-dev] Representing the allocation in CXXNewExpr

[Douglas Gregor]

Sent from my iPhone

On Mar 24, 2012, at 7:06 AM, Sebastian Redl <sebastian.redl at getdesigned.at> wrote:

> 
> On 24.03.2012, at 09:32, Jordan Rose wrote:
> 
>> Hi, all. PR12014 is tracking the analyzer's model of operator new. The bug was originally from Sebastian's refactoring of CXXNewExpr to use a subexpression for the initializer; coupled with the linearization of the analysis CFG, we ended up getting that part of the analysis for free. (That is, just looking at the subexpressions of CXXNewExpr will cause us to analyze the embedded initializer like any other constructor, for those new-expressions that use constructors.)
>> 
>> What we don't have a model for, however, is the allocation, and because of this the constructor doesn't actually have a reasonable "memory region" the analyzer can reason about later. While we could augment the CFG to put a new "allocation" node before the constructor, Ted came up with the question of whether this information ought to be in the AST itself.
>> 
>> I'm definitely not a lawyer on what is supposed to be explicit in the AST and what isn't; this seems to fall on the borderline of the general guideline of "preserve the structure in the original source". Looking at the existing appearances of CXXNewExpr doesn't help either -- adding an allocation sub-expression wouldn't significantly affect any of the existing code positively or negatively, AFAICT.
>> 
>> On the other hand, a new-expression's /behavior/ is basically this:
>> 1. Call the allocation function.
>> 2. If allocation succeeds, call the constructor.
>> 3. If the constructor fails, call the deallocation function.*
>> 
>> Seeing each of those "calls" makes me think something should be abstracted out. The deallocation is a little funny because the arguments have already been evaluated, but the allocation function call really is equivalent to calling an "operator new" function directly.
> 
> I think it would make sense to represent at least the call to operator new as its own CallExpr.

Yes, that makes sense. 

> I'd leave the destructor as a simple FunctionDecl pointer in the CXXNewExpr, though, since correctly modeling that call sounds hard.

Agreed, and there's precedent for just keeping around this pointer rather than forming an AST to call the destructor. 

> Sebastian
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev