<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
于 2012/1/18 0:37, Ted Kremenek 写道:
<blockquote cite="mid:2CD4AF200ED54CE5B4EDB4AFA3F2A4D7@apple.com"
type="cite">
<div><span style="color: rgb(160, 160, 168); ">On Tuesday, January
17, 2012 at 8:22 AM, Erik Verbruggen wrote:</span></div>
<blockquote type="cite"
style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<span>
<div>
<div>
<div>On 17-1-12 7:02, Chandler Carruth wrote:</div>
<blockquote type="cite">
<div>
<div>On Mon, Jan 16, 2012 at 9:29 PM, Ted Kremenek
<<a moz-do-not-send="true"
href="mailto:kremenek@apple.com">kremenek@apple.com</a></div>
<div><<a moz-do-not-send="true"
href="mailto:kremenek@apple.com">mailto:kremenek@apple.com</a>>>
wrote:</div>
<div><br>
</div>
<div> Hi Erik,</div>
<div><br>
</div>
<div> Thanks for working on this. I've commented in
the PR.</div>
<div><br>
</div>
<div> My concern is that I am having second thoughts
about whether or not</div>
<div> this is the right direction. If there are
temporaries in the return</div>
<div> expression, should those destructors appear
before the 'return'</div>
<div> statement (but after the subexpression of
'return' gets evaluated)?</div>
<div> I can see it both ways.</div>
<div><br>
</div>
<div> For example:</div>
<div><br>
</div>
<div> return A();</div>
<div><br>
</div>
<div> where 'A' converts to whatever the return value
type should be, and</div>
<div> ~A() is non-trivial. Technically, ~A() evaluates
after the</div>
<div> enclosing statement. We're giving 'return'
special treatment in</div>
<div> your patch.</div>
<div><br>
</div>
<div> One clean representation of this is to put all
the destructors after</div>
<div> the 'return' in the CFGBlock. The other way is
to have the</div>
<div> destructors appear after the subexpression of
'return', but before</div>
<div> the 'return' itself. The former requires clients
of the CFG to</div>
<div> rethink where they expect 'return' to be in a
CFGBlock.</div>
<div><br>
</div>
<div> What do you think?</div>
<div><br>
</div>
<div><br>
</div>
<div>If I can jump in from the peanut gallery...</div>
<div><br>
</div>
<div>This doesn't seem a necessarily unique problem to
return statements. Any</div>
<div>statement which forms a CFGBlock terminator and
which contains</div>
<div>temporaries with destructors should hit the same
issue. The other</div>
<div>example is I suspect throw. It may even be
possible to trigger this with</div>
<div>an indirect goto if the index into the
label-address array involves</div>
<div>temporary objects.</div>
</div>
</blockquote>
<div><br>
</div>
<div>For a throw it is actually slightly worse: no
implicit destructors calls </div>
<div>get added to the CFG. I did not check the indirect
goto, because I could </div>
<div>not come up with a good example..</div>
<div><br>
</div>
</div>
</div>
</span></blockquote>
<div>For now, just assume that everything with EH in the CFG is
wrong or incomplete. That's a discussion on its own.</div>
<blockquote type="cite"
style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span>
<div>
<div>
<blockquote type="cite">
<div>
<div>I think the C++ standard* provides some help in
making a choice about</div>
<div>how to represent this. It doesn't actually say
that ~A() evaluates after</div>
<div>the enclosing statement. Instead it defines
'full-expressions' as an</div>
<div>expression which is not a subexpression of any
other expression</div>
<div>([intro.execution] 1.9p10). As *part* of this
full-expression, all</div>
<div>temporary objects' non-trivial destructors must
be called</div>
<div>([class.temporary] 12.2p3). To me, that indicates
that the destructor</div>
<div>should be placed after the complete subexpression
in the return</div>
<div>statement, but within the return statement
itself. This has the nice</div>
<div>property of preserving the (very useful!)
invariant that terminator</div>
<div>statements are the last statement in the CFG
block.</div>
</div>
</blockquote>
<div><br>
</div>
<div>This would mean that a full expression of "return
SomeClass();" would </div>
<div>get split in two: all the implicit destructors calls
for the scope get </div>
<div>placed between the return value calculation and the
actual return of </div>
<div>that value.</div>
</div>
</div>
</span></blockquote>
<div>Yes. Exactly. That's the correct semantics</div>
<div> </div>
<blockquote type="cite"
style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span>
<div>
<div>
<div> If you would want to base code generation on the
CFG, it </div>
<div>would force an extra pass to identify whether
calculated values should </div>
<div>be constructed in a return value slot or not. So I
think that using </div>
<div>return/throw (and possibly goto) as markers, would be
a simplification.</div>
</div>
</div>
</span></blockquote>
<div>Concerning "goto" and "throw"; those are terminators and
already can serve as markers. I'll elaborate with the case of
"return". I'm also not certain what you mean by an "extra
pass", but it *might* require some work.</div>
<div><br>
</div>
<div>My concern is that, unlike "goto", the "return" in the CFG is
not a terminator; it doesn't represent a transfer of control.
That's what terminators in CFGBlocks are for. Instead, it
appears in the CFGBlock as an element, which means (in that
context) it represents a statement that gets executed. Since it
doesn't represent the transfer of control in that context, the
sole role of the "return" in the CFG is to represent the binding
of the return value.</div>
<div><br>
</div>
<div>That said, we could place the "return" as a terminator, in
*addition* to what we do now, and have that terminator terminate
the CFGBlock with the destructor calls in it. That terminator
would be on a CFGBlock that transitioned to the Exit block.
Doing this isn't absolutely necessary, but it would annotate
the end of the CFGBlock with the return statement, possibly
making it more amendable to code generation while still
preserving the invariants of the CFG.</div>
</blockquote>
<br>
What is the real benefits of having a ReturnStmt appeared as a
terminator in addition to as a regular element? Not all functions
have return statements.<br>
</body>
</html>