[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAH8yC8mgLs18Wjxz1D1ntbMYK5EiAkWOpLv5y=JYaeymLt1pjw@mail.gmail.com>
Date: Tue, 11 Nov 2025 17:19:27 -0500
From: Jeffrey Walton <noloader@...il.com>
To: musl@...ts.openwall.com
Cc: James Y Knight <jyknight@...gle.com>, Alejandro Colomar <alx@...nel.org>,
The 8472 <the8472.rs@...inite-source.de>, Thiago Macieira <thiago@...ieira.org>,
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 4:07 PM Thorsten Glaser <tg@...lvis.org> wrote:
>
> On Tue, 11 Nov 2025, Rich Felker wrote:
>
> >Is it a single problem or multiple ones that keep getting raised
> >because they seem vaguely related to the topic?
>
> I think the C++ people have a problem that they think they can
> solve with this. I’m not sure whether that prompted Alex’ work
> on a suggestion or whether he’s just invested into changing
> realloc and they jumped on. It does seem like there are also
> other people chiming in, thinking they could possibly use a
> part of this anywhere, but so far, we seem to be getting only
> concrete info out of C++ people.
>
> >I'm still unclear why "size-feedback-malloc" is supposed to be useful
> >enough to justify all of this. It seems like at most it's saving a
> >fairly small % of space at small sizes and an even smaller % (a fixed
> >maximum, the page size) at larger sizes serviced by direct mmap.
>
> It seems like, if C++ has a need that must be served by libc’s
> malloc implementation, then that’s an implementation thing, and
> we don’t need to change the C standard for it, but instead ask
> libc implementors to add a function specifically for the use by
> C++ runtimes (which they can use once they (compile-time) tested
> its availability, over the existing way).
My apologies for being one of "those" people, but...
I thought that is what reserve(..) is for in C++ containers, like
std::string and std::vector:
// size is 0 and capacity is 1024
std::string s;
s.reserve(1024);
// size is now 26, no reallocations
for (char ch='A'; ch<='Z'; ++ch)
s.push_back(ch);
Now the C++ folks have a growable string that does not need reallocations.
> I’ve not yet seen any use of this for C code that doesn’t have
> other downsides that make it improbable to impractical.
Jeff
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.
