From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Detecting use-after-free bugs using gcc's malloc() attribute |
Date: | 2023-07-06 11:52:59 |
Message-ID: | c1eceb84-56f9-3adc-f9ad-c449ca389153@eisentraut.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2023-07-06 12:24:11 | Re: UUID v7 |
Previous Message | Mikhail Gribkov | 2023-07-06 11:52:41 | Re: Permute underscore separated components of columns before fuzzy matching |