Date: Wed, 31 Aug 2022 16:08:17 +0200
From: Joerg Sonnenberger <jo...@bec.de>
Message-ID: <yw9rua3ugm96v...@bec.de>
| I'm poking at this because it ignores consistency with malloc(0).
| malloc(0) and realloc(NULL, 0) should behave the same. Frankly, this
| doesn't seem to be well thought out at all..
Ah, in that case, sorry, there's another sentence I didn't bother to
include, as I didn't think it was relevant - and now it is clear that
it is, that is I was concentrating on the realloc(ptr, 0) (and reallocarray
equivalent) when ptr != NULL, along with the problem of knowing whether
or not the memory ptr points to was freed or not.
The more relevant to your issue sentence from the (forthcoming, sometime,
not this year) version of the posix standard (which will be just a clone
of something from the C standard I assume) is
If ptr is a null pointer, realloc( ) or reallocarray( ) shall be
equivalent to malloc( ) for the specified size.
which I think might be what you wanted to see.
And while I am here, while I won't quote these parts unless someone really
needs to know them, there are words to say that it is undefined what happens
when a (non-NULL) pointer passed to (either) realloc*() function did not
come from one of the malloc() family of calls, or if it had previously been
free()'d.
There's also stuff about there being no guarantees about the order in which
memory is assigned, or that any two blocks will sit next to each other, and
the kind of guarantees that you'd expect about the alignment of the resulting
pointer (etc).
Plus if an ENOMEM occurs, then the memory (if any) which was previously
allocated isn't changed.
Last, implementations are allowed to return EINVAL if realloc*() with a
size of 0 isn't supported.
I think that's all - aside from the basic definition of realloc() which
as best I can tell isn't changed from the previous version.
kre
