[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAA2zVHq4nmbGMGw72BbyYWfcj9dz=cjdf7mL3R1my1xU+-gFAQ@mail.gmail.com>
Date: Tue, 11 Nov 2025 15:36:33 -0500
From: James Y Knight <jyknight@...gle.com>
To: Alejandro Colomar <alx@...nel.org>
Cc: musl@...ts.openwall.com, Rich Felker <dalias@...c.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 Thu, Nov 6, 2025 at 4:49 PM Alejandro Colomar <alx@...nel.org> wrote:
> > Yes, a new malloc variant with direct size feedback would be a much
> > better idea than a new non-moving realloc variant. And, for people who
> > care about usefulness for C++: that's already the direction C++
> > started to go.
>
> I disagree. Most users don't need this, and should use this.
>
> malloc(3) is already a special case of realloc(3), but it's useful
> enough that it warrants a separate function.
>
> However, for the case of realloci(), I don't see the usefulness of a
> hypothetical malloci() to be enough to justify it.
>
> After all, you can do this:
>
> p = malloc(size);
> if (p == NULL)
> goto fail;
>
> actual_size = realloci(p, size);
>
> And the realloci() call should be cheap compared to malloc(3). There's
> absolutely no need to conflate this into a new function. realloci()
> should be enough.
Yes, one could write something like that if realloci was added -- so
long as it had the semantics of potentially allocating a larger size
than was requested (which I don't think was the actual proposal?).
But, it would be somewhat less efficient and as useful for C++ than
size-feedback-malloc would be. My point was: that it'd be better to
add size-feedback-malloc INSTEAD of realloci -- not in addition.
As has been stated multiple times, realloc on most modern malloc
implementations can't typically grow an allocation, beyond the small
amount of growth into the padding space for the implementation's
chosen size bucket. And when you're talking about small growth like
that, it is substantially less expensive to have an API to tell the
allocator to give you that otherwise-wasted memory up-front, from the
initial allocation.
> And the realloci() call should be cheap compared to malloc(3).
realloci will not be cheap enough to be ignorable. At the very least,
it needs to look up the size bucket for the pointer passed to it,
which can be a significant overhead by itself. That's the entire
reason C++ added a sized delete, see (from 2013)
https://wg21.link/n3536.
> But, there's no need to rush the growth.
Please see the section in the doc,
https://wg21.link/p0401r6#reallocation which explicitly discusses and
rejects an 'in-place realloc'. If you want to defer growth, you need
to add a new branch to the control flow for growing the buffer. That
would be a significant overhead compared to simply setting a slightly
larger capacity up-front, which can be provided for free by the malloc
implementation at the point of allocation.
> I don't see this being used in C, so I think the C implementation should
> be just enough to allow C++ to do their thing. For that, realloci()
> would be enough. C++ can call it immediately after malloc(3) if needed,
> and can wrap it with the malloci() from above if they want.
Er, what?
One _could_ do that, but it would be exceedingly silly to add a brand
new realloci API with the justification that it's "useful for
C++"...when it's not. Only to wrap it -- with a substantial
performance cost! -- to act like size-feedback-malloc, which is the
API that would actually be useful.
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.
