<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I'm a bit late to the party, but..<div><br></div><div>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.</div><div><br></div><div>Regarding the <span class="Apple-style-span" style="font-size: 13px; ">PreStmt<CXXNewExpr>, perhaps we could trigger it when encountering the allocation CFG node (before allocation/initialisation), and then trigger the </span><span class="Apple-style-span" style="font-size: 13px; ">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.</span></div><div><span class="Apple-style-span" style="font-size: 13px;"><br></span></div><div><span class="Apple-style-span" style="font-size: 13px;">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.</span></div><div><span class="Apple-style-span" style="font-size: 13px;"><br></span></div><div><span class="Apple-style-span" style="font-size: 13px;">Looking forward to other opinions.</span></div><div><span class="Apple-style-span" style="font-size: 13px;"><br></span></div><div><span class="Apple-style-span" style="font-size: 13px;">Tom</span></div><div><span class="Apple-style-span" style="font-size: 13px;"><br></span><div><div>On 04/04/2012, at 9:05 PM, Jordan Rose wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<div>
<div class="BodyFragment"><font size="2"><span style="font-size:10pt;">
<div class="PlainText">Updated patch that doesn't crash horribly on trunk.<br>
<br>
</div>
</span></font></div>
<div class="BodyFragment"><font size="2"><span style="font-size:10pt;">
<div class="PlainText"><br>
<br>
<br>
On Apr 4, 2012, at 13:06, Jordan Rose wrote:<br>
<br>
> 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.<br>
> <br>
> Missing pieces:<br>
> <br>
> - 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.)<br>
> <br>
> - 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.<br>
> <br>
> Anyway, how does this part look?<br>
> Jordy<br>
> <br>
> <CFGAllocation.patch><br>
<br>
</div>
</span></font></div>
<div class="BodyFragment"><font size="2"><span style="font-size:10pt;">
<div class="PlainText">_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div>
</span></font></div>
</div>
<span><CFGAllocation.patch></span></blockquote></div><br></div></body></html>