[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <yniy5shbgv6bdmzl523ezxoxotrgdxbt243ejzmydqbljpszcy@coacvzzyb45b>
Date: Wed, 5 Nov 2025 12:24:14 +0100
From: Alejandro Colomar <alx@...nel.org>
To: Rich Felker <dalias@...c.org>
Cc: Demi Marie Obenour <demiobenour@...il.com>, musl@...ts.openwall.com,
The 8472 <the8472.rs@...inite-source.de>, Thiago Macieira <thiago@...ieira.org>,
Florian Weimer <fw@...eb.enyo.de>, libc-alpha@...rceware.org,
Arthur O'Dwyer <arthur.j.odwyer@...il.com>, Jonathan Wakely <jwakely@...hat.com>
Subject: Re: Re: realloci(): A realloc() variant that works in-place
Hi Rich, Demi,
On Tue, Nov 04, 2025 at 11:56:54PM -0500, Rich Felker wrote:
> On Tue, Nov 04, 2025 at 07:37:41PM -0500, Demi Marie Obenour wrote:
> > > This "useful" needs to be quantified. Only in very very rare cases
> > > will in-place expansion even be possible. The vast majority of the
> > > time, you must allocate another discontiguous chunk to meet the above
> > > contractual obligation anyway.
> >
> > Would it be better to provide an allocation API that returns the amount
> > of memory actually allocated? That would at least allow any padding at
> > the end of the allocation to be used instead of being wasted.
>
> No, that was a mistake made long ago with malloc_usable_size and
> wrongly equating "amount actually allocated" with "amount we could
> enlarge the allocation up to without running into something else".
Agree. If an API tells the size of the block, it must internally set
the size of the block to that. That way, there's an opt-in to the
decreased safety. For most users, you want to use only what you asked
for, which makes _FORTIFY_SOURCE and other tools provide safety for your
code.
> Equating them is wrong because (1) the compiler will rightly treat
> accesses beyond the requested size at allocation time, even if
> malloc_usable_size reports more and the allocator implementation lets
> you use more, as UB, and (2) allowing the use of "extra space" here
> precludes detecting overflows. It really is necessary, if you want to
> allow the application to use extra space, to have some interface by
> which it's requested. However, I don't think anyone has made a
> compelling case yet that doing this is useful enough to be worth the
> trouble and possible unforseen bad consequences -- keep in mind the
> bad consequences of malloc_usable_size were entirely unseen at the
> time it was sloppily introduced.
Agree. Before adding realloci(), I'd like to see numbers. An
interesting thing to do would be to see some application that uses
realloc(3) currently, and check how often realloc(3) doesn't move the
object. (To test that without UB, one needs to do the trick with
uintptr_t.)
Otherwise, we should presume that realloci() would fail always, and
wouldn't be useful.
Have a lovely day!
Alex
>
> Rich
--
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).
Download attachment "signature.asc" of type "application/pgp-signature" (834 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.
