On Apr 4, 2013, at 5:40 PM, Jordan Rose <[email protected]> wrote:
> > 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. 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 > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
