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
signature.asc
Description: PGP signature
