| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Peter Eisentraut <peter(at)eisentraut(dot)org>, Tristan Partin <tristan(at)partin(dot)io>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Add malloc attribute to memory allocation functions |
| Date: | 2026-07-07 22:58:14 |
| Message-ID: | ak2EhhPxWaxPigsc@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jul 07, 2026 at 11:53:36AM -0400, Tom Lane wrote:
> 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.
Additional question. Does this help with requirements like the one
listed in fe-exec.c for PQfreemem() under WIN32? If the answer to
this question is yes, then it would sound like a win for me, we'd had
our share of issues in the past where we would use a free() call that
interacts with an allocation done in a completely different context
library-wise. That's something WIN32 cares a lot about, to mention
one place.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christoph Berg | 2026-07-07 22:58:59 | Re: WAL compression setting after PostgreSQL LZ4 default change |
| Previous Message | Jelte Fennema-Nio | 2026-07-07 22:46:53 | Re: WAL compression setting after PostgreSQL LZ4 default change |