[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2537904.56niFO833r@tjmaciei-mobl5>
Date: Fri, 31 Oct 2025 08:35:36 -0700
From: Thiago Macieira <thiago@...ieira.org>
To: musl@...ts.openwall.com, libc-alpha@...rceware.org,
musl@...ts.openwall.com, "A. Wilcox" <AWilcox@...cox-tech.com>,
Lénárd Szolnoki <cpp@...ardszolnoki.com>,
Thorsten Glaser <tg@...bsd.de>, Collin Funk <collin.funk1@...il.com>,
Laurent Bercot <ska-dietlibc@...rnet.org>
Cc: 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 Friday, 31 October 2025 07:13:24 Pacific Daylight Time Laurent Bercot wrote:
> What problem is realloci() a solution to? In what circumstance would
> a programmer want to use it rather than realloc?
This is very common in C++ but as Alex has pointed out, it happens in C too
when the caller code checks if the pointer changed and thus needs to perform
extra work.
In C++, most of the time in generic code, we simply cannot use realloc() in
the first place, because the container does not know if the object in question
can be memcpy()ed around. Some language has been added to the C++26 standard
to begin addressing this, which was the origin of this discussion. If the
container does not know this, then it must:
1) allocate a brand, new block
2) iterate over the elements in the container, asking the object to
move+destroy/relocate itself
3) free the old block
A resize-in-place operation that did not move would allow the container to be
much faster, especially if the move+destroy operation is in any way expensive.
It will increase the size of emitted code, but not by much and has a great
potential upside.
> In most cases, it will be very difficult for an implementation to
> increase the size of an allocated block without relocating the block.
> So you can expect realloci() to fail often.
Fail often is fine, though I dispute that a bit. The common case I can think of
is when a generic container is being populated without being told its final
target size. This implies the container is growing as elements are appended.
For an allocator implementation without slabs, which can allocate regions of
any size next to each other, the heap ahead is often free, so the block can be
grown in place by simple adjusting of the size.
Without the realloci() function, a generic container will keep performing the
three operations above. And since the new block is always bigger than the
previous usually by a factor of 2x, there's never enough free space in the
heap before it, so the heap keeps growing. If they don't, then adding ~8000
256-byte objects to a container will use approximately 4 MB of heap, not 2 MB,
unless they perform MADV_DONTNEED on free().
> What should users do in that case?
>
> - Fail? the program will not be reliable at all. Who wants that?
> - Fall back on realloc()? then the workarounds for relocation need to
> be implemented anyway, so why not use realloc() in the first place?
Neither.
The fallback is to malloc() + object-specific callback + free().
--
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.
