[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c3036054-32fd-4349-b85c-3b17ebc549ef@cs.ucla.edu>
Date: Fri, 31 Oct 2025 21:54:52 -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 17:27, Thiago Macieira wrote:
> I don't think you are because imposing this requirement would imply it will
> never memcpy() the data to a new location and that would break quite a lot of
> applications that depend the ability to grow a block so long as there's heap
> available.
You're right I'm not saying that. All I'm saying is that when
R=realloc(P,N) succeeds, you can assume that you can adjust old pointers
into the object addressed by P by adding R-P to them. The C standard
says this results in undefined behavior; all that we need to do is fix
the C standard to say it's well-defined (because it is on practical
platforms).
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.
