[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5304256.ogB4TqSGss@tjmaciei-mobl5>
Date: Fri, 31 Oct 2025 10:53:27 -0700
From: Thiago Macieira <thiago@...ieira.org>
To: Alejandro Colomar <alx@...nel.org>, 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>, Oliver Hunt <oliver@...le.com>
Subject: Re: Re: realloci(): A realloc() variant that works in-place
On Friday, 31 October 2025 10:31:54 Pacific Daylight Time Paul Eggert wrote:
> On 10/31/25 11:25, Thiago Macieira wrote:
> > I think the Committee would balk at adding a function
> > that takes a pointer to already-freed memory whose purpose is to allow the
> > contents of the new object to be adjusted solely based on arithmetic.
>
> Do you know of any platforms where this does not in fact work? Other
> than sanitizing platforms that go to some lengths to impose the
> Committee's rules even though the hardware would work fine?
>
> If not, then perhaps we can convince the Committee that the mismatch
> between the current rules and reality is causing real harm, and that
> it'd be a win for C's users to change the standard to match reality better.
Oliver, please comment on ARM64e if you can, for pointer authentication. Think
not just of statically-known pointers like vtables, but the general case of
pointer authentication.
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.
This function for libstdc++'s std::string would look something like:
// can't call old->_M_is_local() or old->_M_local_data(), so we must
// use pointer arithmetic
uintptr_t old_local_data = old + offsetof(std::string, _M_local_buf);
if (uintptr_t(object->_M_data()) == old_local_data) {
// was using Small String Optimization
object->_M_data(object->_M_local_data())
}
I trust libstdc++ developers to know how to write this. I trust myself and
some colleagues for some Qt classes, and I trust developers in folly and
abseil for similar things. Like I said, a few dozen people on the planet.
And unlike Standard Library developers we'd probably have to err on the side
of caution with some compilers, and thus disallow the object being relocated
in the first place. For example, the offsetof() above is only implementation-
defined, for many types. That limits the usefulness of the feature.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Principal Engineer - Intel Data Center - Platform & Sys. Eng.
Download attachment "signature.asc" of type "application/pgp-signature" (871 bytes)
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.
