From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
Cc: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Expand palloc/pg_malloc API |
Date: | 2022-09-14 04:35:57 |
Message-ID: | 2521438.1663130157@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2022-09-14 04:37:38 | Re: archive modules |
Previous Message | Justin Pryzby | 2022-09-14 04:34:19 | Re: failing to build preproc.c on solaris with sun studio |