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

[Anna Zaks]

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

> 
> On Dec 19, 2012, at 12:30 , Anna Zaks <ganna at apple.com> wrote:
> 
>> 
>> 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.
> 
> Well, the family currently has no use at all, but my original impression was that its primary use was to specify the free function (or set of free functions). The secondary use could be to add reasoning about pointer aliasing, but we don't have that hooked up either.
> 
> The advantage I see of directly specifying the free function is that it makes things instantly extensible, but then why do we have the family at all? (Maybe we should take the family out instead.)
> 

I see how it's used, you basically pass the family name as the first parameter to all the attributes, which belong to one family. By passing it as the first parameter to the free function, you associate the allocation and deallocation functions. Makes sense to me.

Anna.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121219/f55ba650/attachment.html>