[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fh34pureqgk72w2czvrllpnsbxlww3mbicow4dsnipn2w5w452@x4qwbaxys7x6>
Date: Sun, 2 Nov 2025 14:31:59 +0100
From: Alejandro Colomar <alx@...nel.org>
To: Thiago Macieira <thiago@...ieira.org>
Cc: Florian Weimer <fw@...eb.enyo.de>, libc-alpha@...rceware.org,
musl@...ts.openwall.com, Arthur O'Dwyer <arthur.j.odwyer@...il.com>,
Jonathan Wakely <jwakely@...hat.com>
Subject: Re: realloci(): A realloc() variant that works in-place
Hi Thiago,
On Sat, Nov 01, 2025 at 12:40:41PM -0700, Thiago Macieira wrote:
> On Saturday, 1 November 2025 09:14:24 Pacific Daylight Time Alejandro Colomar
> wrote:
> > - It will never fail. It always allocates a size >=MIN(oldsize, size).
> >
> > - When shrinking, either it does actually shrink (if the space can be
> > reused by others), or returns a large size if that space would anyway
> > be wasted.
> >
> > - When growing, it grows to the first step at least as large as the
> > requested size if possible, or it grows as much as possible. Then
> > it's up to the caller to judge if that's enough. For example:
> >
> > actual_size = realloci(p, requested_size);
> > if (actual_size < needed_size)
> > do_actual_realloc();
> >
> > Does this sound good for std::vector?
>
> Yes.
>
> I'm pondering whether to also add the "extra" parameter from xallocx(), thus
> making it nearly the same API. I can't think of a good reason, because like
> your proposal, it's documented to
>
> "The xallocx() function returns the real size of the resulting resized
> allocation pointed to by ptr, which is a value less than size if the
> allocation could not be adequately grown in place. "
>
> This means it always returns a value between
> cursize
> and
> ROUND_UP(newsize+extra, blocksize)
>
> Under what circumstances would it make any use of the separation of the two
> values? Is it to make upper layers simpler, by having a constant in the extra
> parameter? Or is it maybe to avoid them having to deal with overflow in the
> addition or multiplication? Does anyone know? We should probably ping Jason
> Evans.
>
> I can see where it's used in the source code, but I haven't spent enough time
> to understand what decisions it may do differently.
I'm writing a format prroposal for wg14, and while writing the wording,
I think I don't see a reason for overallocating this extra.
The purpose of realloci() is being extremely cheap. So, why would one
ask for extra size? You could just keep calling realloci() every time,
and let the allocator grow in small steps. That would simplify the
implementation of the caller, which doesn't need have code for growing
in large steps.
If the caller needs 37 kiB, it should ask for exactly 37 kiB. The
allocator would likely give 40 kiB. Then the caller will ask again when
it needs 41 kiB. Why would the caller want to allocate something like
64 kiB (just as an example), but then be happy with 37? This call is
much cheaper than an actual move with realloc(3) or malloc(3)+free(3).
So, why not require the caller to not ask too much? We could go back to
reporting an error if there's not enough memory.
Of course, it would still guarantee no errors when shrinking, but
I think we could error out when growing.
Unless there's a reason for the user to attempt to overallocate that I'm
not seeing.
#define realloci(p, size) reallocarrayi(p, size, 1)
ssize_t reallocarrayi(void *p, size_t n, size_t eltsize);
The returned value of reallocarrayi() would be the number of elements
actually allocated, which would be guaranteed to be either >= n, or -1
or error. There would be a further guarantee that it wouldn't error
when n <= oldsize.
n = reallocarrayi(p, 37, sizeof(T));
if (n == -1)
goto fail;
...
n = reallocarrayi(p, 41, sizeof(T));
if (n == -1)
goto fail;
Have a lovely day!
Alex
--
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).
Download attachment "signature.asc" of type "application/pgp-signature" (834 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.
