On Tue Jul 7, 2026 at 10:34 AM CDT, Peter Eisentraut wrote: > On 06.07.26 18:34, Tristan Partin wrote: >> On Mon Jul 6, 2026 at 4:26 AM UTC, Tom Lane wrote: >>> "Tristan Partin" <[email protected]> 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.
We could add -Wno-analyzer-malloc-leak to backend code. -- Tristan Partin PostgreSQL Contributors Team AWS (https://aws.amazon.com)
