Re: unhide reallocarray

[Joerg Sonnenberger <joerg%bec.de@localhost>]

Am Wed, Aug 31, 2022 at 08:33:18PM +0700 schrieb Robert Elz:
> This is all, according to the application usage section, because of what
> the C standard is planning to do:
> 
>    The description of realloc( ) has been modified from previous versions
>    of this standard to align with the ISO/IEC 9899:1999 standard. Previous
>    versions explicitly permitted a call to realloc(p, 0) to free the space
>    pointed to by p and return a null pointer. While this behavior could be
>    interpreted as permitted by this version of the standard, the C language
>    committee has indicated that this interpretation is incorrect. Applications
>    should assume that if realloc( ) returns a null pointer, the space pointed
>    to by p has not been freed. Since this could lead to double-frees,
>    implementations should also set errno if a null pointer actually indicates
>    a failure, and applications should only free the space if errno was changed.
> 
> and in Future Directions:
> 
>    This standard defers to the ISO C standard. While that standard currently
>    has language that might permit realloc(p, 0), where p is not a null
>    pointer, to free p while still returning a null pointer, the committee
>    responsible for that standard is considering clarifying the language to
>    explicitly prohibit that alternative.

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..

Joerg