Re: Add malloc attribute to memory allocation functions

Peter Eisentraut <peter(at)eisentraut(dot)org> writes:
> On 06.07.26 18:34, Tristan Partin wrote:
>> On Mon Jul 6, 2026 at 4:26 AM UTC, Tom Lane wrote:
>>> 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.

> 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.

Yeah, I was thinking about that last point. The frontend environment
is a lot closer to the semantics these markers expect, so we could
try doing this in frontend only and see how well that works.

There are still places that I'd expect to be trouble. For example,
Coverity has never understood the pattern we use in pg_dump's data
collection subroutines, ie, malloc a big array of structs, fill
the individual structs and insert pointers to them into the hash
tables, done. It always thinks we leaked the array, and I suspect
tools like this will too. In Coverity's case there's enough
infrastructure to dismiss individual false-positive complaints,
and then it won't bug you about them (until somebody changes the
relevant code enough that the dismissal doesn't match :-(). Unless
there's some similar way to silence individual reports, I don't
foresee tools like this to be usable. We're not going to change
coding patterns like that one just because some static analyzer
doesn't understand them.

regards, tom lane