| 
  | 
Message-ID: <87seex52qz.fsf@mid.deneb.enyo.de> Date: Sat, 01 Nov 2025 13:57:56 +0100 From: Florian Weimer <fw@...eb.enyo.de> To: Paul Eggert <eggert@...ucla.edu> Cc: Alejandro Colomar <alx@...nel.org>, 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>, Thiago Macieira <thiago@...ieira.org> Subject: Re: Re: realloci(): A realloc() variant that works in-place * Paul Eggert: > On 10/31/25 10:22, Alejandro Colomar wrote: >> Paul, for context, this is a discussion for adding a function >> >> int realloci(void *p, size_t n); >> >> that changes the size of a memory block without moving it. (And thus, >> fails rather often, for some implementations of allocators.) > > Reading the threads leading into this, the motivation for this seems to > be C++ and similar memory allocators that want a cheap way to grow an > object - if the object doesn't move they can skip some reinitialization > work, otherwise they have more work to do. > > With that in mind, the proposed API is not the best way to go about the > problem. What these users want is a function that acts just like > R=realloc(P,N) EXCEPT that it lets you compare R==P, and if the two > values are the same pointer you know the object did not move and you can > skip some work. This is simpler than realloci because it means that you > need only one call (not two) in the common case when realloci returns > the null pointer. This would not help C++ because C++ doesn't have this kind of in-place adjust-all-pointers operation. There's just copy and move, and both need non-overlapping old and new storage at the same time.
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.