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

[Anna Zaks]

On Jan 8, 2013, at 12:01 AM, Scott Parlane <scott at scottnz.com> wrote:

> On Wed, 2012-12-19 at 12:33 -0800, 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 would favor using the family name for identifying the free function to
> use.
> 
> How and to which class were you going to attach the information about
> which allocator family the data is from ?
> 

This would need to be stored in RefState. For example:
Kind: Allocated
Module/Family: "malloc"

Though, for efficiency reasons, we might not want to store the string in the ProgramState but rather some ID that maps back to the family string.

Anna.