r178814 - [analyzer] Reduced the unwanted correlations between checkers living inside MallocChecker.cpp

[Anna Zaks]

On Apr 4, 2013, at 5:40 PM, Jordan Rose <jordan_rose at apple.com> wrote:

> 
> On Apr 4, 2013, at 17:33 , Anton Yartsev <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> 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
> 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/20130405/a94f6e2e/attachment.html>