Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5784342.ZASKD2KPVS@tjmaciei-mobl5>
Date: Sun, 02 Nov 2025 16:56:02 -0800
From: Thiago Macieira <thiago@...ieira.org>
To: Arthur O'Dwyer <arthur.j.odwyer@...il.com>
Cc: Alejandro Colomar <alx@...nel.org>, Florian Weimer <fw@...eb.enyo.de>,
 libc-alpha@...rceware.org, musl@...ts.openwall.com,
 Jonathan Wakely <jwakely@...hat.com>
Subject: Re: realloci(): A realloc() variant that works in-place

On Sunday, 2 November 2025 15:55:53 Pacific Standard Time Arthur O'Dwyer wrote:
> But this whole (bunch of) thread(s) started because of Thiago's throwaway
> comment along the lines of "C++ doesn't care about realloc because realloc
> has a bad API," and I think this thread (these threads) are just driving
> that point home. If I wanted to reach a good allocator API, "I wouldn't
> start from here." I don't think one can design a good allocator API by
> making a ton of tiny patches on top of `malloc` and `realloc`. You have to
> design the API first, and then show how to implement `malloc` and `realloc`
> in terms of it. (Also, C++ couldn't use it without also redesigning
> `std::allocator`, which is almost just a thin wrapper around `malloc` and
> `free`. `std::allocator` doesn't even have a counterpart to `realloc` at
> the moment.)

Indeed, and that is something the C++ Committee will need to figure out. As it 
stands, it won't be able to benefit from realloci. I have a few ideas, which we 
can discuss back in std-proposals/discussion.

But QVector, QString and QByteArray will, because we *have* a different 
allocator interface that would allow retrying with smaller values and fine-
tuning. In fact, QString and QByteArray already use realloc(), because we know 
for sure the container's element type is most trivially relocatable: char and 
char16_t. Other C++ libraries not using std::allocator will benefit from this 
too. As will C libraries operating on arrays.

-- 
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.