[musl] Re: realloci(): A realloc() variant that works in-place

[Jeffrey Walton]

On Tue, Nov 11, 2025 at 4:07 PM Thorsten Glaser <tg@evolvis.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