[cfe-dev] RFC: static analysis, malloc annontation for return via pointer argument

[Anna Zaks]

On Dec 19, 2012, at 12:18 PM, Jordan Rose wrote:

> 
> On Dec 19, 2012, at 12:05 , Anna Zaks <ganna at apple.com> wrote:
> 
>> It feels like attributes are not strong enough to represent the complex relationships in the general case. Even if we managed to make it work, the annotations would look non-intuitive. It would be great to have a more general system to summarize the effects of the functions/represent pre and post conditions.
>> 
>> On Dec 18, 2012, at 12:13 PM, Scott Parlane wrote:
>> 
>>> Hi Ted,
>>> 
>>> I believe it should take 3 parameters.
>>> - which argument is being used to return
>>> - whether the ret value and pointer are associated
>>> (and how, invalid if < 0, != 0 , 0)
>>> - what the size is (this is complicated)
>>> 
>>> lets take the case of asprintf()
>>> return argument is 1, ret == -1 is invalid,
>>> size is (ret+1) * sizeof(pointeeetype)
>>> 
>>> now the api from our codebase we are trying to analyze
>>> int avl_create (struct avl_tree **avl_tree, int max_nodes, int (*compare_function) (void *data1, void *data2))
>>> return argument is 1, ret != 0 is invalid,
>>> size is fixed at sizeof(struct avl_tree)
>>> also, it will leak if not free'd with the correct function, however we
>>> can deal with that issue separately.
>>> 
>> 
>> I think specifying a custom free function is very important (even more than the size) since this is what the malloc checker is supposed to check for. This could be solved by specifying the corresponding free function's name in the attribute. 
> 
> This is what the family is for. Or rather, what it was intended for, since no one added code to make anything other than "malloc" work.

Using the existing family, how the relation between the family name and the free functions is specified?

Specifying a free function directly does have a negative, where it's not as clean to support multiple free functions, but I am not convinced that it's worse than the family.