Re: Expand palloc/pg_malloc API

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Expand palloc/pg_malloc API
Дата
Msg-id 2521438.1663130157@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Expand palloc/pg_malloc API  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Ответы Re: Expand palloc/pg_malloc API  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Justin Pryzby
Дата:
Сообщение: Re: failing to build preproc.c on solaris with sun studio
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: archive modules