[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87o6pl52dm.fsf@mid.deneb.enyo.de>
Date: Sat, 01 Nov 2025 14:05:57 +0100
From: Florian Weimer <fw@...eb.enyo.de>
To: Alejandro Colomar <alx@...nel.org>
Cc: libc-alpha@...rceware.org, musl@...ts.openwall.com, Arthur O'Dwyer
<arthur.j.odwyer@...il.com>, Jonathan Wakely <jwakely@...hat.com>,
Thiago Macieira <thiago@...ieira.org>
Subject: Re: realloci(): A realloc() variant that works in-place
* Alejandro Colomar:
> A discussion within the C++ std-proposals@ mailing list triggered the
> discussion about the need for a realloc() variant that works in-place,
> that is, that doesn't move the address of the memory, and thus that
> doesn't invalidate existing pointers derived from it.
> void *realloci(void *p, size_t size);
The caller won't have sufficient information to determine good values
for size.
For the std::vector case at least, what applications want is some form
of non-moving realloc that allows the application to specify an
arithmetic progression and an interval, and the realloc variant should
change the size of the allocation to an element of the arithmetic
progression that resides within the specified interval, or fail.
With this interface, std::vector would not have to know the size
classes of the allocator. On failure, std::vector resizing would have
to fall back to malloc/free and moving objects one by one. But that
is kind of inevitable.
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.
