Feedback-ID: ie0a040ee:Fastmail
Message-ID: <2248c1c4-68f7-46dc-9e58-9ba9057da74e@eisentraut.org>
Date: Tue, 7 Jul 2026 17:34:43 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Add malloc attribute to memory allocation functions
To: Tristan Partin <tristan@partin.io>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
References: <DJNFBUWD276K.2OPIYJQS75W84@partin.io>
 <924283.1783312014@sss.pgh.pa.us> <DJRMU1Z9461P.184EDJQZ9DH8D@partin.io>
Content-Language: en-US
From: Peter Eisentraut <peter@eisentraut.org>
In-Reply-To: <DJRMU1Z9461P.184EDJQZ9DH8D@partin.io>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/2248c1c4-68f7-46dc-9e58-9ba9057da74e%40eisentraut.org>
Precedence: bulk

On 06.07.26 18:34, Tristan Partin wrote:
> On Mon Jul 6, 2026 at 4:26 AM UTC, Tom Lane wrote:
>> "Tristan Partin" <tristan@partin.io> writes:
>>> Given that we now have a tree that compiles fine against
>>> -Werror=mismatched-dealloc, we need to make sure that we don't regress.
>>> By adding the malloc attribute[0], we can protect against regressions,
>>> enable more accurate code coverage with -fanalyzer, and allow the
>>> compiler to do some optimizations.
>>
>> I'm skeptical that this is going to lead to anything but grief.
>> In particular, since gcc has never heard of memory contexts,
>> I don't see how we are not going to get buried in bogus
>> -Wanalyzer-malloc-leak warnings.  It doesn't really help
>> to add compiler annotations that only sort-of match our semantics.
>>
>> (This opinion is based on years of dismissing useless Coverity
>> warnings of this kind.)
> 
> This is a fair criticism. On master, the number of
> -Wanalyzer-malloc-leak warnings is 62. With this patch applied, it
> balloons to 598.

But this can also check for a lot more, such as

- mismatching deallocator
- double free
- use after free
- free of things that are not an allocation

If we could tell it, check for all these things but don't worry about 
the leaks, that could be useful.

Also, for frontend tools, libpq, etc. that don't use memory contexts.