[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87seeyex7l.fsf@igel.home>
Date: Fri, 31 Oct 2025 19:35:10 +0100
From: Andreas Schwab <schwab@...ux-m68k.org>
To: Thiago Macieira <thiago@...ieira.org>
Cc: Alejandro Colomar <alx@...nel.org>, Paul Eggert <eggert@...ucla.edu>,
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>, Oliver Hunt <oliver@...le.com>
Subject: Re: Re: realloci(): A realloc() variant that works in-place
On Okt 31 2025, Thiago Macieira wrote:
> But I think any such thing would be extremely fragile. Very low-level library
> authors can probably get it right, but I wouldn't trust this feature to more
> than a few dozen people on the planet. We're talking about something like:
>
> void adjust_after_relocation(T *object, uintptr_t old) // or ptr_bits<T>
>
> The temptation is too great to cast the old to a T* and dereference it, which
> is UB because the memory has been freed, but will "happen to work" for
> sufficiently many executions that it might go unnoticed. Then there's the issue
> that the relocated T *object is itself in an inconsistent state and one must
> avoid calling most functions on it.
And it will not be thread safe. The freed memory can be allocated to
another thread any time.
--
Andreas Schwab, schwab@...ux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
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.
