> On Sep 3, 2014, at 7:27 PM, Jordan Rose <[email protected]> wrote: > > [+Anna, Anton] This does seem very much like a new allocation family. Do we > have a policy on how we're going to handle these in general, though? The > MacOSKeychainAPIChecker also handles allocation-like tracking, as does > SimpleStreamChecker. What does everyone think we should do? > > My personal opinion (though without thinking too long) is that aggregating > new allocators under MallocChecker is the right thing to do for now—i.e. we > should take this patch. We may even want to come up with a way to make this > nicely extensible/configurable in the future.
This particular patch - a different kind of allocator seems like a perfect fit for the MallocChecker the way it is. > But there are a lot of APIs that work this way, so… I agree that MacOSKeychainAPI has a lot in common with MallocChecker and it would be beneficial to unify them. > > (We can keep SimpleStreamChecker distinct even if we fold fopen/fclose under > MallocChecker, since it's still a good example of how the analyzer works.) > > Jordan > > > On Aug 26, 2014, at 8:45 , Daniel Fahlgren <[email protected] > <mailto:[email protected]>> wrote: > >> Hi, >> >> The MallocChecker does currently not track the memory allocated by >> if_nameindex. That memory is dynamically allocated and should be freed >> by calling if_freenameindex. The attached patch teaches the checker >> about these functions. >> >> Memory allocated by if_nameindex is treated as a separate allocation >> "family". That way the checker can verify it is freed by the correct >> function. >> >> Any comments / feedback? >> >> Best regards, >> Daniel Fahlgren >> <ifnameindex.patch>
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
