Re: Detecting use-after-free bugs using gcc's malloc() attribute - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Detecting use-after-free bugs using gcc's malloc() attribute
Date
Msg-id c1eceb84-56f9-3adc-f9ad-c449ca389153@eisentraut.org
Whole thread Raw
In response to Re: Detecting use-after-free bugs using gcc's malloc() attribute  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On 28.06.23 20:15, Andres Freund wrote:
> On 2023-06-28 10:40:22 +0200, Peter Eisentraut wrote:
>> On 26.06.23 21:54, Andres Freund wrote:
>>> For something like pg_list.h the malloc(free) attribute is a bit awkward to
>>> use, because one a) needs to list ~30 functions that can free a list and b)
>>> the referenced functions need to be declared.
>>
>> Hmm.  Saying list_concat() "deallocates" a list is mighty confusing because
>> 1) it doesn't, and 2) it might actually allocate a new list.
> 
> list_concat() basically behaves like realloc(), except that the "pointer is
> still valid" case is much more common.  And the way that's modelled in the
> annotations is to say a function frees and allocates.
> 
> Note that the free attribute references the first element for list_concat(),
> not the second.

Yeah, I think that would be ok.  I was worried about the cases where it 
doesn't actually free the first argument, but in all those cases it 
passes it as a result, so as far as a caller is concerned, it would 
appear as freed and allocated, even if it's really the same.




pgsql-hackers by date:

Previous
From: Mikhail Gribkov
Date:
Subject: Re: Permute underscore separated components of columns before fuzzy matching
Next
From: Daniel Gustafsson
Date:
Subject: Re: UUID v7