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

[Anna Zaks]

On Apr 19, 2013, at 9:52 AM, Anna Zaks <ganna at apple.com> wrote:

> 
> On Apr 19, 2013, at 2:45 AM, Anton Yartsev <anton.yartsev at gmail.com> wrote:
> 
>> On 29.03.2013 4:00, Anna Zaks wrote:
>>> I've committed the new callback. Looks like no email was sent out.. So just look at r178310.
>> +static bool retTrue(const RefState *RS) {
>> +  return true;
>> +}
>> +
>> +static bool checkIfNewOrNewArrayFamily(const RefState *RS) {
>> +  return (RS->getAllocationFamily() == AF_CXXNewArray ||
>> +          RS->getAllocationFamily() == AF_CXXNew);
>> +}
>> ...........
>> +      if (RS->isAllocated() && CheckRefState(RS))
>>         State = State->remove<RegionState>(sym);
>>     }
>>   }
>> 
>> Anna, could you, please, clarify why we only process C++ families on const escape here?
>> 
> 
> Because we assume that the user can call 'delete' on a const pointer, but cannot call 'free' on it.

As described in the commit message:

    [analyzer] Add support for escape of const pointers and use it to allow “newed” pointers to escape
    
    Add a new callback that notifies checkers when a const pointer escapes. Currently, this only works
    for const pointers passed as a top level parameter into a function. We need to differentiate the const
    pointers escape from regular escape since the content pointed by const pointer will not change;
    if it’s a file handle, a file cannot be closed; but delete is allowed on const pointers.
    
    This should suppress several false positives reported by the NewDelete checker on llvm codebase.

I think in your case, a content of const pointer escaping, we are expecting the other callback to get triggered. Since if a const pointer points to another pointer, which is non-const, the other pointer escapes, not const-escapes.

> 
>> -- 
>> Anton
> 
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

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