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