Hi Jordan, I agree with you that this seems like the right approach. We probably should rename MallocChecker at some point however to reflect it's more generalized behavior.
Ted > 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. But there are a lot of APIs > that work this way, so... > > (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]> 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
