[Re-adding bug-gnulib in CC, because this discussion is generally interesting]
Hi Pádraig,
Pádraig Brady wrote:
> > size_t n = 10;
> > void *p = malloc (n);
> > ...
> > for (;;)
> > {
> > ...
> > n = ...; /* larger than the original n */
> > p = realloc (p, n);
> > }
>
> I'm sorry Bruno, I don't follow exactly.
> Note the characteristics I posted, i.e.
>
> malloc (0)==valid_ptr
> realloc (valid_ptr,0)==NULL
> realloc (NULL,0)==valid_ptr
>
> were from glibc itself, not rpl_realloc.
> I think rpl_realloc tries to ensure that
> NULL is only returned on error, though I'm
> not sure given all the ifdefs used.
Ok, I admit that my previous explanations were terse.
1. Let's look at what the 'realloc' module *currently* guarantees.
It does guarantee that
realloc (NULL,0)==valid_ptr
but nothing about realloc (valid_ptr,0) - because on glibc systems,
rpl_realloc is not used and glibc behaves like you discovered.
2. Let's look at what the 'realloc' module *should* guarantee, once
we fix it. gnulib tries hard not to create overrides of functions defined
in glibc, because we want executables on glibc systems to be as slim as
possible, and because gnulib is in the same boat as glibc. Should we file
an enhancement request for glibc, asking them to guarantee that
realloc (valid_ptr,0) != NULL except upon error?
I can already imagine Ulrich Drepper's answer to such a request:
1. The POSIX standard does not guarantee it,
2. glibc is being in use without this guarantee for 12 years, this
proves that it's not a problem.
So, assuming glibc does not change, gnulib's 'realloc' module cannot
guarantee more than it currently does.
3. Now let's look in which situations the 'realloc' module is useful.
I cannot find a reasonable and straightforward way of using realloc()
in a way that works with the current guarantees of the 'realloc' module
and does not work with just the POSIX guarantees.
As a consequence, I claim that the 'realloc' module is not generally
useful, and should be deprecated because it leads people into thinking
that it provides guarantees like xrealloc(), which it doesn't.
> Perhaps we should have a single realloc-posix
> module that behaves as glibc does now.
No no, a module with suffix '-posix' is meant to provide the POSIX
guarantees for the function and not more. (Cf. for example, the
fnmatch-posix and fnmatch-gnu modules.)
Bruno
