Bruno Haible wrote:
> Pádraig Brady wrote:
>> ... 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?
>
> This wa
Bruno Haible writes:
> Simon Josefsson wrote:
>> What about a realloc-gnu which implements a behaviour we think it is
>> useful? I know that we used -gnu for modules that are glibc extensions
>> over POSIX
>
> Yes, the two standards to which gnulib leans are POSIX and glibc's behaviour.
>
>> but
Simon Josefsson wrote:
> What about a realloc-gnu which implements a behaviour we think it is
> useful? I know that we used -gnu for modules that are glibc extensions
> over POSIX
Yes, the two standards to which gnulib leans are POSIX and glibc's behaviour.
> but I think we could extend it to be
Pádraig Brady wrote:
> ... 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?
This way of checking realloc's return val
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 */
>>>
Bruno Haible writes:
>> 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.)
What
[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);
> >
Pádraig Brady wrote:
> I wrote a quick test program on glibc-2.7 to show:
> malloc (0)==valid_ptr
> realloc (valid_ptr,0)==NULL
> realloc (NULL,0)==valid_ptr
> The interesting case there is the middle one which is not
> covered by the AC_FUNC_REALLOC check as far as I can see.
I confirm your
I was looking at what was provided by the realloc module in gnulib
and was a bit confused. There was no texi info on it and the description
in modules/realloc just says "realloc() function that is glibc compatible".
For me, that wasn't enough info to infer how I should use realloc().
The module ch
