Re: Expand palloc/pg_malloc API - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Expand palloc/pg_malloc API
Date
Msg-id 1606160.1652813031@sss.pgh.pa.us
Whole thread Raw
In response to Re: Expand palloc/pg_malloc API  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses Re: Expand palloc/pg_malloc API
List 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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Tracking notnull attributes inside Var
Next
From: Robert Haas
Date:
Subject: Re: Zstandard support for toast compression