On Apr 4, 2013, at 17:33 , Anton Yartsev <[email protected]> wrote:
> On 05.04.2013 3:52, Jordan Rose wrote:
>>
>> On Apr 4, 2013, at 16:46 , Anton Yartsev <[email protected]> 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_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
