[cfe-dev] Check virtual calls in ctor or dtor

[章磊]

2011/12/10 Ted Kremenek <kremenek at apple.com>

> On Dec 1, 2011, at 7:08 PM, 章磊 wrote:
>
> I think the last approach is a good choice, it's simple and clear.
>
> But i have two minor problems.
>
>
>    1. 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?
>
> 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.
>
> I could be missing something.  Shouldn't this work?
>

Sounds great. I will implement this in my later patch.

>
>    1. 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.
>
> 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.
>



-- 
Best regards!

Lei Zhang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20111212/b0720fe0/attachment.html>