[PATCH][Review request] unix.Malloc checker improvement: +handling new/delete, +memory.MismatchedFree, +memory.MismatchedDelete, +improved display names for allocators/deallocators

[Anton Yartsev]

On 29.03.2013 22:04, Anna Zaks wrote:
>
> On Mar 28, 2013, at 5:42 PM, Anton Yartsev <anton.yartsev at gmail.com 
> <mailto:anton.yartsev at gmail.com>> wrote:
>
>>>> Evolved one more problem to solve: if overloaded standard operator 
>>>> new is defined and is called as a function, then it is not 
>>>> recognized as overloaded operator for some reason. Tests 
>>>> testOpNewArray() and testOpNew() in NewDelete-custom.cpp cover 
>>>> these issue.
>>>
>>> You can check if it has to do with redeclarations of the allocator 
>>> function, but I wouldn't expect that. Definitely something we need 
>>> to fix before putting out another open-source checker build.
>> Addressed the issue. Actually the problem is caused by the fact, that 
>> overloaded operator new was inlined and has not been processed by 
>> checkPostStmt(const CallExpr) at all as it skips inlined calls.
>> What Is the reason for skipping inline calls?
>>
>
> The idea is that if a function has been inlined, it will be modeled 
> through inlining where we will know exactly what it does.
>
> It is unclear if we should enforce the malloc/free, new/delete rules 
> on inlined functions. For example, in this case, if someone overloaded 
> the operator new, do we want to ensure that delete was called on the 
> object regardless of what new's custom implementation is?
It seems to me that if we just simply handle inline functions without 
analyzing the implementation it'll give less false-positives then 
false-negatives if we just skip them as most malloc/new functions are 
expected to allocate memory. Or I haven't got something?

-- 
Anton

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130329/a3f1bb98/attachment.html>