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

[章磊]

Hi Ted,

I re-implement this checker as you suggested.

Based on your suggestion, I modified two minor places for the bug
report generation.

   1. Use CallExpr instead of FunctionDecl as the WorkList unit.
   2. Introduced a pointer point to the the CallExpr whose body is
current walking.

I test this patch on some real code base, and it seems to work well.

More comments inline, and looking forward to your reply.

2011/12/12, 章磊 <ioripolo at gmail.com>:
> 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
>


-- 
Best regards!

Lei Zhang
-------------- next part --------------
A non-text attachment was scrubbed...
Name: virtualcall.patch
Type: text/x-patch
Size: 10061 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20111225/abccbcb1/attachment.bin>