[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251110012023.GD1827@brightrain.aerifal.cx>
Date: Sun, 9 Nov 2025 20:20:23 -0500
From: Rich Felker <dalias@...c.org>
To: Paul Eggert <eggert@...ucla.edu>
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 Sun, Nov 09, 2025 at 11:03:52AM -0800, Paul Eggert wrote:
> 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.
The only way the lifetime of P does not end is if realloc returns a
null pointer indicating failure. On success, it is as if
malloc+memcpy+free.
Rich
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.
