[musl] Re: realloci(): A realloc() variant that works in-place

[Thiago Macieira]

On Friday, 31 October 2025 15:25:20 Pacific Daylight Time Paul Eggert wrote:
> Using 7th Edition Unix realloc does not ignore that case. The idea is
> that you call realloc; if it gives you the same pointer you're done,
> otherwise you update the object's contents inplace accordingly. It's the
> same basic idea as realloci where, if realloci fails you malloc
> something larger, and copy from the old object to the new while updating
> the contents of the new object as needed. This is the same amount of
> updating work either way; it's just that it's a simpler allocator API
> and that simplicity is easier to document/implement/explain and is
> likely to help performance a bit too.

I'm not sure I understand you.

Are you saying that 7th Edition Unix realloc() returned only one of two 
possible values?

 NULL on failure
 the same ptr that was passed as input on success

I don't think you are because imposing this requirement would imply it will 
never memcpy() the data to a new location and that would break quite a lot of 
applications that depend the ability to grow a block so long as there's heap 
available.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel Data Center - Platform & Sys. Eng.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 870 bytes
Desc: This is a digitally signed message part.
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20251031/b482e86d/attachment.sig>