FAQ
I was thinking a bit more about Alvaro's suggestion of the other day
that repalloc(NULL, size) should be allowed. I'm still convinced that
that's a bad idea, but it occurs to me that there is another corner
case in the palloc stuff that there's a better case for changing.
Specifically, I think we ought to allow palloc(0) and repalloc(x, 0).
What these should do is return a *non-NULL* pointer to a chunk of
minimum size.

The reason I'm thinking this is that I've lost count of the number of
places where we are kluging around the fact that palloc(0) elog's.
In most places the easiest fix is to waste storage, eg when you want
an array of n foo's you write something like

ptr = palloc(n * sizeof(foo) + 1);

if it's legitimate for n to be zero. This is confusing, wasteful,
and error-prone. (I'm sure there are still a bunch of places yet to
be found where we fail on zero-column tables because the +1 hasn't
gotten added.)

It's important that palloc(0) return an actual chunk, and not NULL,
for two reasons:

* If the result is later repalloc'd larger, it should stay in the
context that palloc was called in. There is no way to remember
that context without a chunk.

* The result should be pfree'able. I don't want to remove the
prohibition against pfree(NULL).

But assuming that we don't return NULL, this seems fully consistent
with the rest of the palloc API. It certainly doesn't break any
code that works today, and I think the change would eliminate many
special cases as well as future bug fixes.

Comments, objections?

regards, tom lane

Search Discussions

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedJun 4, '04 at 4:52p
activeJun 4, '04 at 4:52p
posts1
users1
websitepostgresql.org...
irc#postgresql

1 user in discussion

Tom Lane: 1 post

People

Translate

site design / logo © 2021 Grokbase