[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4300643.WSEgdgrriA@tjmaciei-mobl5>
Date: Fri, 31 Oct 2025 14:06:10 -0700
From: Thiago Macieira <thiago@...ieira.org>
To: Paul Eggert <eggert@...ucla.edu>, Alejandro Colomar <alx@...nel.org>
Cc: libc-alpha@...rceware.org, musl@...ts.openwall.com,
"A. Wilcox" <AWilcox@...cox-tech.com>,
Lénárd Szolnoki <cpp@...ardszolnoki.com>,
Collin Funk <collin.funk1@...il.com>,
Arthur O'Dwyer <arthur.j.odwyer@...il.com>,
Jonathan Wakely <jwakely@...hat.com>, "Paul E. McKenney" <paulmck@...nel.org>
Subject: Re: Re: realloci(): A realloc() variant that works in-place
On Friday, 31 October 2025 13:13:42 Pacific Daylight Time Alejandro Colomar
wrote:
> Consider that realloci() would be significantly cheaper than realloc(3),
> so even if you have an extra function, it might be worth it if it
> succeeds a non-negligible number of times.
>
> From what Thiago says, it seems that it would be worth it for them.
> I suspect it's because things like std::string often grow or shrink by
> small amounts compared to the previous size, as operations on strings
> don't change their length significantly quite often.
Note I'm not talking about growing/shrinking std::strings themselves, but
growing/shrinking arrays (std::vector) of std::strings. The libsdc++
std::string is 32 bytes in size and is not relocatable via memcpy()able.
> So, while it would be one more call in user code, that call is very
> cheap, and the code is really simple to use too:
>
> if (realloci(p, size) == -1)
> fall_back_to_expensive_path();
That's what my example on Godbolt did too.
> I wouldn't categorize it as hard to explain:
>
> int realloci(void *p, size_t size);
>
> realloci() changes the size of the memory block pointed to by
> 'p' to 'size' bytes. This is done in-place, that is, without
> changing its address.
>
> The contents of the memory will be unchanged in the range from
> the start of the region up to the minimum of the old and new
> sizes. If the new size is larger than the old size, the added
> memory will not be initialized.
I'd add: if the new size is smaller than the old size, the bytes in that
storage are undefined, even if this function returned -1. That will allow an
implementation to MADV_DONTNEED the space, even if it can't officially change
the size of the allocation.
Would it be worth returning instead the new size, which may be bigger than the
requested size?
--
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.
