[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251111224545.GG1827@brightrain.aerifal.cx>
Date: Tue, 11 Nov 2025 17:45:45 -0500
From: Rich Felker <dalias@...c.org>
To: Thiago Macieira <thiago@...ieira.org>
Cc: James Y Knight <jyknight@...gle.com>,
Alejandro Colomar <alx@...nel.org>, musl@...ts.openwall.com,
The 8472 <the8472.rs@...inite-source.de>,
Florian Weimer <fw@...eb.enyo.de>, libc-alpha@...rceware.org,
Arthur O'Dwyer <arthur.j.odwyer@...il.com>,
Jonathan Wakely <jwakely@...hat.com>
Subject: Re: Re: realloci(): A realloc() variant that works in-place
On Tue, Nov 11, 2025 at 01:59:19PM -0800, Thiago Macieira wrote:
> On Tuesday, 11 November 2025 12:51:28 Pacific Standard Time Rich Felker wrote:
> > What is the actual problem folks are trying to solve?
> >
> > Has that ever been stated clearly?
>
> Yes, more than once: growing a container (array, usually) that holds objects
> with non-trivial copy/move operations. realloc() is unsuitable for that
> because the elements can't be memmove()d, so containers today must allocate a
> new buffer, perform the expensive move, then free the old buffer.
And that's still going to happen. The only difference is the exact
thresholds at which it happens, and having slightly less memory
overhead along the way. If the problem is "moving objects is expensive
and we don't want to do that", nothing on this path does anything to
solve it.
Rich
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.
