<br><br><div class="gmail_quote">2011/12/10 Ted Kremenek <span dir="ltr"><<a href="mailto:kremenek@apple.com">kremenek@apple.com</a>></span><br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="word-wrap:break-word"><div><div class="im"><div>On Dec 1, 2011, at 7:08 PM, ียภฺ wrote:</div><br><blockquote type="cite"><span style="border-collapse:separate;font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium">I think the last approach is a good choice, it's simple and clear.<br>
<br>But i have two minor problems.<br><br><ol><li>When we do (b)(ii), we may find many calls not already in the PreVisit or PostVisit state, then we will add them to the stack. So the complete stack is not a  call stack, right? Then we may need a iterator  point to the "call stack" top?</li>
</ol></span></blockquote></div><div>Assuming the "stack" is implemented as a vector, where we push PreVisit/PostVisit on the end, I think you can recover the correct call stack by only looking at your ancestors that are in the PostVisit state.  You then just skip those in the vector in the PreVisit state, as those represents functions whose bodies still need to be analyzed.  This approach only works if your worklist algorithm is DFS.  The invariant there is that the only functions in the PostVisit state are those guaranteed to be your ancestors in the DFS traversal, while anything in the PreVisit state might be a sibling, a cousin, etc.</div>
<div><br></div><div>I could be missing something.  Shouldn't this work?</div></div></div></blockquote><div><br>Sounds great. I will implement this in my later patch. <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="word-wrap:break-word"><div><div class="im"><blockquote type="cite"><span style="border-collapse:separate;font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><ol start="2">
<li>In your former mail, you mentioned that "For each constructor/destructor, only report calling a specific virtual function once." IMO, we may need to report all the calls to a specific virtual function, these information may help the users to find out where is the exact place in the call path to fix these problems. But it may seems to noisy, so we may need a new bug report mechanism to make this kind of report clear.</li>
</ol></span></blockquote></div></div><div>Fair points.  Another way to look at it is that one path gets reported, the user fixes it, and re-runs the analyzer to see if any problems remain.  I'm fine with going for the simpler approach for now of just reporting everything, and see how bad it is in practice.</div>
</div></blockquote></div><br><br clear="all"><br>-- <br>Best regards!<br><br>Lei Zhang<br>