Re: realloc documentation

[Pádraig Brady]

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.