[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d0cbb553-49f0-462d-b681-818f648e8dda@cs.ucla.edu>
Date: Fri, 31 Oct 2025 16:25:20 -0600
From: Paul Eggert <eggert@...ucla.edu>
To: Thiago Macieira <thiago@...ieira.org>, 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 10/31/25 15:14, Thiago Macieira wrote:
> that ignores the very common case of data not being allowed to move, which
> precludes using realloc() in the first place, even if it would have kept the
> pointers intact.
Using 7th Edition Unix realloc does not ignore that case. The idea is
that you call realloc; if it gives you the same pointer you're done,
otherwise you update the object's contents inplace accordingly. It's the
same basic idea as realloci where, if realloci fails you malloc
something larger, and copy from the old object to the new while updating
the contents of the new object as needed. This is the same amount of
updating work either way; it's just that it's a simpler allocator API
and that simplicity is easier to document/implement/explain and is
likely to help performance a bit too.
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.
