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

From Tom Lane
Subject Re: Expand palloc/pg_malloc API
Date
Msg-id 2521438.1663130157@sss.pgh.pa.us
Whole thread Raw
In response to Re: Expand palloc/pg_malloc API  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: Expand palloc/pg_malloc API
List pgsql-hackers
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> I have another little idea that fits well here: repalloc0 and 
> repalloc0_array.  These zero out the space added by repalloc.  This is a 
> common pattern in the backend code that is quite hairy to code by hand. 
> See attached patch.

+1 in general --- you've put your finger on something I felt was
missing, but couldn't quite identify.

However, I'm a bit bothered by the proposed API:

+extern pg_nodiscard void *repalloc0(void *pointer, Size size, Size oldsize);

It kind of feels that the argument order should be pointer, oldsize, size.
It feels even more strongly that people will get the ordering wrong,
whichever we choose.  Is there a way to make that more bulletproof?

The only thought that comes to mind offhand is that the only plausible
use-case is with size >= oldsize, so maybe an assertion or even a
runtime check would help to catch getting it backwards.  (I notice
that your proposed coding will fail rather catastrophically if the
caller gets it backwards.  An assertion failure would be better.)

            regards, tom lane



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: failing to build preproc.c on solaris with sun studio
Next
From: Peter Eisentraut
Date:
Subject: Re: archive modules