public inbox for [email protected]  

help / color / mirror / Atom feed

From: Michael Paquier <[email protected]>
To: Tom Lane <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: Tristan Partin <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: Add malloc attribute to memory allocation functions
Date: Wed, 8 Jul 2026 07:58:14 +0900
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

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


Attachments:

  [application/pgp-signature] signature.asc (833B, ../[email protected]/2-signature.asc)
  download

view thread (10+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Add malloc attribute to memory allocation functions
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox