Why repalloc() != realloc() ?

Alvaro Herrera <alvherre@dcc.uchile.cl> writes:

Is there a reason why repalloc() does not behave the same as realloc?
realloc(NULL, size) behaves the same as malloc(size), and it seems
useful behavior -- I wonder why repalloc() chooses to Assert() against
this exact condition?

We don't allow palloc(0) either, and we don't return NULL on failure,
and for that matter we don't allow pfree(NULL). Please don't argue that
"we ought to be just like libc".

I assume this is because the NULL pointer would not know what context it
belongs to,

That's a sufficient reason from my point of view. One of the main
properties of repalloc is that the alloc'd memory stays in the same
context it was first allocated in. I'm not excited about allowing
a special exception that makes that behavior less predictable.

To give a concrete example of why this sort of corner-case exception is
bad, imagine an aggregate function or similar thing that concatenates
strings. It starts with a palloc() in a specific context and then
assumes that repalloc's will stay in that context without prodding.
The code works fine --- unless there are corner cases for palloc(0)
returning NULL and repalloc() accepting NULL.

Can this behavior be changed?

Not without a significantly better argument than you've offered.

regards, tom lane

On Tue, Jun 01, 2004 at 11:39:57PM -0400, Tom Lane wrote:

I assume this is because the NULL pointer would not know what context it
belongs to,

That's a sufficient reason from my point of view.

Right, you've convinced me. Just wanted to know if I could save three
lines of code. Probably not a compelling reason to change the behavior.

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"El realista sabe lo que quiere; el idealista quiere lo que sabe" (An�nimo)