[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5bb19374-4715-4bc4-ad0c-d5f357db839f@cs.ucla.edu>
Date: Sun, 9 Nov 2025 11:03:52 -0800
From: Paul Eggert <eggert@...ucla.edu>
To: Rich Felker <dalias@...c.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>, Thiago Macieira <thiago@...ieira.org>,
Alejandro Colomar <alx@...nel.org>
Subject: Re: Re: realloci(): A realloc() variant that works in-place
On 2025-11-09 10:11, Rich Felker wrote:
> On Sun, Nov 09, 2025 at 06:38:25PM +0100, Alejandro Colomar wrote:
>> My point was that it's easier to consider the lifetime of P ends at
>> every realloc(3) call than to consider it to end only if Q!=P.
>
> I agree with this.
? The lifetime of P does not necessarily end after Q=realloc(P,N), even
in C23. So the situation is already more complicated than Alejandro's
incorrect summary, and for good reason. And there should be nothing
wrong with adjusting this part of the standard to better reflect how
real-world implementations behave.
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.
