r178814 - [analyzer] Reduced the unwanted correlations between checkers living inside MallocChecker.cpp
Anton Yartsev
anton.yartsev at gmail.com
Fri Apr 5 12:11:07 PDT 2013
On 05.04.2013 21:21, Anna Zaks wrote:
> On Apr 4, 2013, at 5:40 PM, Jordan Rose <jordan_rose at apple.com
> <mailto:jordan_rose at apple.com>> wrote:
>
>>
>> On Apr 4, 2013, at 17:33 , Anton Yartsev <anton.yartsev at gmail.com
>> <mailto:anton.yartsev at gmail.com>> wrote:
>>
>>> On 05.04.2013 3:52, Jordan Rose wrote:
>>>>
>>>> On Apr 4, 2013, at 16:46 , Anton Yartsev <anton.yartsev at gmail.com
>>>> <mailto:anton.yartsev at gmail.com>> wrote:
>>>>
>>>>> + if (Family == AF_Malloc &&
>>>>> + (!Filter.CMallocOptimistic && !Filter.CMallocPessimistic))
>>>>> + return false;
>>>>> +
>>>>> + if ((Family == AF_CXXNew || Family == AF_CXXNewArray) &&
>>>>> + !Filter.CNewDeleteChecker)
>>>>> + return false;
>>>>> +
>>>>> + return true;
>>>>> +}
>>>>> +
>>>>> +bool MallocChecker::isTrackedFamily(CheckerContext &C,
>>>>> + const Stmt *AllocDeallocStmt)
>>>>> const {
>>>>> + return isTrackedFamily(getAllocationFamily(C, AllocDeallocStmt));
>>>>> +}
>>>>> +
>>>>> +bool MallocChecker::isTrackedFamily(CheckerContext &C, SymbolRef
>>>>> Sym) const {
>>>>> + const RefState *RS = C.getState()->get<RegionState>(Sym);
>>>>> +
>>>>> + return RS ? isTrackedFamily(RS->getAllocationFamily())
>>>>> + : isTrackedFamily(AF_None);
>>>>> +}
>>>>
>>>> Uh, this is not correct; this will say that AF_None is a tracked
>>>> family, which means any symbol with no RefState has a tracked family.
>
> If we are tracking the symbol we should know it's family. Family is a
> heuristic, it does not have to be that we necessarily saw the
> allocation function. So in the cases below, I would expect
>
>>> This is made for cases:
>>>
>>> int i;
>>> free(&i);
>>>
> &i belongs to malloc family after free is processed.
>>> and similar.
>>> We may add something like assert(family != AF_None) somewhere else
>>> if AF_None is not acceptable. How do you think?
>>
>> Hm, good point. That seems like a case where the family of the symbol
>> doesn't matter, though—it's the family of the deallocator that
>> matters. If NewDeleteChecker is disabled, we should not warn about this:
>>
>> int i;
>> delete &i;
> &i belongs to CXXNew and delete family after delete is processed.
>>
>> Even though we won't get here, I think it's still better to be safe
>> than sorry, and say that AF_None is untracked.
>> Jordan
>> _______________________________________________
>> cfe-commits mailing list
>> cfe-commits at cs.uiuc.edu <mailto:cfe-commits at cs.uiuc.edu>
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
Anna, your comments gave me an idea how to fix all the issues with
unknown family in the single place, applied the fix at r178899. Thanks! :)
--
Anton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130405/68958743/attachment.html>
More information about the cfe-commits
mailing list