<br><br><div class="gmail_quote">2010/8/11 Ted Kremenek <span dir="ltr"><<a href="mailto:kremenek@apple.com">kremenek@apple.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Marcin,<br>
<br>
First, I want to thank you for working on this. Adding support for destructors, and possibly scopes, to the CFG is something that is sorely needed for analyzing C++ code.<br>
<br>
At the risk of sounding pedantic, I think when evaluating our possible approaches it's really important to keep in mind both *how* the information in the CFG will be used to service clients and *what* information the CFG is meant to represent. Second, I think we shouldn't focus on the implementation details (e.g., "the builder is processing AST backwards") of how we would construct the information before we have an idea of what the right API is for accessing the information in its final form. The whole point of the CFG is to make it easier to write analyses, so having a good API that represents useful information is the primary goal.<br>
<br>
That's all well and good, but what does that mean? First let's step back and examine what purpose the CFG serves. The CFG is meant to represent control-flow in a function; nothing more and nothing less. Representing the control-flow is important for any analyses we want to build on top of the CFG that want to know the ordering between statements, the change of control caused by jumps and loops, etc. With this in mind, let's consider both the problem of scopes and destructors.<br>
<br>
>From your proposal of CFGScope, if you take a look at the definition it actually has nothing to do with control-flow at all. In C and its derivatives, scope is purely a lexical concept. This is evident since Sema and the Parser reason about scopes but don't actually reason about control-flow. If you renamed 'CFGScope' to 'ASTScope' then it functionally would be the same thing. Thus in my mind tying it to CFGs really has no value, and conflates our mental model of what the CFG does. I think it's reasonable to consider building ASTScopes (or whatever they are called) as part of the process of building a CFG (sort of a by-product), but unless the scope information is valuable to model in the CFG as something a client of the CFG would want to know about *when reasoning about control-flow* then I think it is an orthogonal topic. Before I believe I argued that this information could be represented in the CFG, but I'm honestly not certain what benefit that would provide other than modeling when we cross scope boundaries. That information, however, can likely be constructed by analysis using a side map from statements to scope, so it's not clear if that needs to be in the CFG.<br>
</blockquote><br></div>It seems that gcc's gimple cfg has the same idea.<br><br><div style="margin-left: 40px;"><font style="color: rgb(0, 0, 153);" size="1">int main() {<br> int x;<br> {<br> int y;<br> {<br>
int z;<br> }<br> }<br>}</font><br></div><br>gcc's tree cfg :<br><br><div style="margin-left: 40px;"><font size="1"><span style="color: rgb(0, 0, 153);">;; Function main (main)</span><br style="color: rgb(0, 0, 153);">
<br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 102, 0);">Scope blocks:</span><br style="color: rgb(0, 102, 0);"><br style="color: rgb(0, 102, 0);"><span style="color: rgb(0, 102, 0);">{ Scope block #0 </span><br style="color: rgb(0, 102, 0);">
<span style="color: rgb(0, 102, 0);"> int x; (unused)</span><br style="color: rgb(0, 102, 0);"><br style="color: rgb(0, 102, 0);"><span style="color: rgb(0, 102, 0);"> { Scope block #0 </span><br style="color: rgb(0, 102, 0);">
<span style="color: rgb(0, 102, 0);"> int y; (unused)</span><br style="color: rgb(0, 102, 0);"><br style="color: rgb(0, 102, 0);"><span style="color: rgb(0, 102, 0);"> { Scope block #0 </span><br style="color: rgb(0, 102, 0);">
<span style="color: rgb(0, 102, 0);"> int z; (unused)</span><br style="color: rgb(0, 102, 0);"><br style="color: rgb(0, 102, 0);"><span style="color: rgb(0, 102, 0);"> }</span><br style="color: rgb(0, 102, 0);"><br style="color: rgb(0, 102, 0);">
<span style="color: rgb(0, 102, 0);"> }</span><br style="color: rgb(0, 102, 0);"><br style="color: rgb(0, 102, 0);"><span style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 102, 0);">}</span><br><br style="color: rgb(0, 0, 153);">
</span><span style="color: rgb(0, 0, 153);">main ()</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);">{</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> int z;</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> int y;</span><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"> int x;</span><br style="color: rgb(0, 0, 153);"><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);"><bb 2>:</span><br style="color: rgb(0, 0, 153);">
<span style="color: rgb(0, 0, 153);"> return;</span><br style="color: rgb(0, 0, 153);"><br style="color: rgb(0, 0, 153);"><span style="color: rgb(0, 0, 153);">}</span><br></font></div><br><br><br><br clear="all"><br>-- <br>
Best regards!<br><br>Lei Zhang<br>