Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3499967.iC22s8V5EV@tjmaciei-mobl5>
Date: Sat, 01 Nov 2025 08:42:30 -0700
From: Thiago Macieira <thiago@...ieira.org>
To: Florian Weimer <fw@...eb.enyo.de>
Cc: Alejandro Colomar <alx@...nel.org>, libc-alpha@...rceware.org,
 musl@...ts.openwall.com, Arthur O'Dwyer <arthur.j.odwyer@...il.com>,
 Jonathan Wakely <jwakely@...hat.com>
Subject: Re: realloci(): A realloc() variant that works in-place

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.

Download attachment "signature.asc" of type "application/pgp-signature" (871 bytes)

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.