Re: Expand palloc/pg_malloc API

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2022-05-17T18:43:51Z
Lists: pgsql-hackers
Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> writes:
> On Tue, May 17, 2022 at 5:11 PM Peter Eisentraut
> <peter.eisentraut@enterprisedb.com> wrote:
>> This adds additional variants of palloc, pg_malloc, etc. that
>> encapsulate common usage patterns and provide more type safety.

> I see lots of instances where there's no explicit type-casting to the
> target variable type -
>         retval = palloc(sizeof(GISTENTRY));
>         Interval   *p = palloc(sizeof(Interval));
>         macaddr    *v = palloc0(sizeof(macaddr)); and so on.

Yeah.  IMO the first of those is very poor style, because there's
basically nothing enforcing that you wrote the right thing in sizeof().
The others are a bit safer, in that at least a human can note that
the two types mentioned on the same line match --- but I doubt any
compiler would detect it if they don't.  Our current preferred style

         Interval   *p = (Interval *) palloc(sizeof(Interval));

is really barely an improvement, because only two of the three types
mentioned are going to be checked against each other.

So I think Peter's got a good idea here (I might quibble with the details
of some of these macros).  But it's not really going to move the
safety goalposts very far unless we make a concerted effort to make
these be the style everywhere.  Are we willing to do that?  What
will it do to back-patching difficulty?  Dare I suggest back-patching
these changes?

			regards, tom lane



Commits

  1. Add repalloc0 and repalloc0_array

  2. Expand palloc/pg_malloc API for more type safety

  3. Assorted examples of expanded type-safer palloc/pg_malloc API