Bruno Haible wrote:
> [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.)
Thanks for the clarification Bruno.
So if we deprecate the realloc module (because we need to use the
POSIX interface anyway to detect realloc(NULL,0)==NULL)
and just go with realloc-posix then we need to use realloc like this I think:
errno=0
np = realloc (p, n);
if (np==NULL && errno==ENOMEM) {
free (p);
error ();
}
I.E. xrealloc etc. should be changed to check ENOMEM as above?
cheers,
Pádraig.
