realloci(): A realloc() variant that works in-place

[Thiago Macieira]

On Saturday, 1 November 2025 08:14:05 Pacific Daylight Time Florian Weimer 
wrote:
> I assume the document here is current?
> <https://jemalloc.net/jemalloc.3.html>
> 
> The description is not very precise.  I think for avoiding
> fragmentation, it would be desirable for xallocx to return values
> great than size + extra if there's a tail that cannot be used by
> another allocation.  It's unclear whether that's permitted.
> But with a few clarifications, xallocx might indeed be a simpler
> interface for this.

Agreed. It would be very much implementation-dependent, though.

In other words, xallocx() may return any value greater than the *current* 
size, which may be smaller than the new desired minimum.

In one scenario, let's say you have a block of currently 2304 bytes and you're 
asking for 2560 bytes with an extra 512 "if it won't bother you". But this 
already is in the 4096-byte slab, so all allocations are of that size and 
don't fit the 2048 one. So it will return 4096.

In another, let's say you have a block of 1920 bytes and you make the same 
request. As it can't grow past 2048 without memcpy(), it will return 2048, 
which is less than the requested minimum of 2560. In this case, it's up to the 
caller to decide to malloc() a new block, as it really needs that new minimum.

-- 
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/20251101/ab37b841/attachment-0001.sig>