[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5730038.rdbgypaU67@tjmaciei-mobl5>
Date: Tue, 11 Nov 2025 19:56:35 -0800
From: Thiago Macieira <thiago@...ieira.org>
To: musl@...ts.openwall.com, noloader@...il.com
Cc: James Y Knight <jyknight@...gle.com>, Alejandro Colomar <alx@...nel.org>,
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 Tuesday, 11 November 2025 14:19:27 Pacific Standard Time Jeffrey Walton
wrote:
> Now the C++ folks have a growable string that does not need reallocations.
If you know the end size, even a rough estimate of it, by all means use it. An
overestimation is probably worth the trade-off for not needing to reallocate.
The problem is when the user doesn't know the end size, such as when parsing
some input that doesn't come with a size prepended. Or when the user simply
fails to call such function because it isn't *necessary*, just an
optimisation.
BTW, that reminds me of the dual of container growth: the shrink_to_fit()
operation. Some developers may reserve() too much and then shrink_to_fit() the
memory. If the contained type can't be memmove()d around, the container
implementation may opt to not give the memory back in the first place. If we
did have realloci(), we could signal to the memory allocator that a portion of
the memory is now free for new allocations - whether that implementation can
make use of it will be implementation-dependent.
--
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.
