[cfe-dev] Adding a CFG node for the allocation call in a new-expression

[Tom Care]

I'm a bit late to the party, but..

I like this approach, it should be enough to start with. I have a very hacked approach in my own tree for handling new re: checker work I'm doing, but I like the idea of the CFG node better.

Regarding the PreStmt<CXXNewExpr>, perhaps we could trigger it when encountering the allocation CFG node (before allocation/initialisation), and then trigger the PostStmt<CXXNewExpr> as normal after encounting the new expression? It kind of breaks the generalised pre/post visit that we plan to implement, but maybe that will be a problem solved by the abstract call model you propose.

Another thing that Ted, Zhongxing and I discussed off-list was making a new memory region type specifically for C++ allocated memory regions. We don't currently have anything that completely matches the model (typed, system allocated, independent.) I've been using a hacked together version of this to help detect mismatched (de)allocations involving new/delete.

Looking forward to other opinions.

Tom

On 04/04/2012, at 9:05 PM, Jordan Rose wrote:

> Updated patch that doesn't crash horribly on trunk.
> 
> 
> 
> 
> On Apr 4, 2012, at 13:06, Jordan Rose wrote:
> 
> > Hi, Ted (and list). After the negative feedback on representing new-expression allocations using CXXOperatorCallExpr, I went back to the original idea of adding a CFG node. Without properly modelling constructors this doesn't gain us very much right now, but it does set the stage for eventually being able to get all of the behavior of a new-expression into the analyzer.
> > 
> > Missing pieces:
> > 
> > - What does it mean to be PreStmt<CXXNewExpr> if the allocation and the initializer have already happened? (Note that right neither PreStmt nor PostStmt checks are done on CXXNewExpr, but that's easily fixed.)
> > 
> > - How can we represent "calls" that don't have associated expressions? I'm starting to think CallOrObjCMessage needs to turn into a real "abstract call" model which may or may not have expressions for the arguments and can handle regular calls, messages, constructors, destructors, allocations, and deletions.  New checks: preCall and postCall. But that's a bit outside the scope of this patch.
> > 
> > Anyway, how does this part look?
> > Jordy
> > 
> > <CFGAllocation.patch>
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> <CFGAllocation.patch>

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