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

[Jordan Rose]

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.
> This is made for cases:
> 
> int i;
> free(&i);
> 
> 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;

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130404/984c872c/attachment.html>