[PATCH] make analyzer track memory allocated by if_nameindex

[Anna Zaks]

The bodies of these functions look very similar. Please, try to factor out the copy and paste.
+bool MallocChecker::isIfNameFunction(const FunctionDecl *FD,
+bool MallocChecker::isIfFreeNameFunction(const FunctionDecl *FD, ASTContext &C) const {

Otherwise, looks good to me.

Thank you!
Anna.

> On Sep 22, 2014, at 9:20 AM, Daniel Fahlgren <daniel at fahlgren.se <mailto:daniel at fahlgren.se>> wrote:
> 
> Hi,
> 
> On Wed, 2014-09-03 at 19:27 -0700, Jordan Rose 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
> 
> Ping. What is the next step for this patch, is more work needed? Is
> there something that I should do?
>> 
>> 
>> On Aug 26, 2014, at 8:45 , Daniel Fahlgren <daniel at fahlgren.se <mailto:daniel at fahlgren.se>> 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?
>>> 
> Cheers,
> Daniel Fahlgren

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140922/b9fb23b0/attachment.html>