[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <52kv6rea3qrxhmn7eicthxynv7stmrsrunjjrqdmvai3r7u7sd@va76o6cnmot3>
Date: Mon, 3 Nov 2025 10:36:07 +0100
From: Alejandro Colomar <alx@...nel.org>
To: Rich Felker <dalias@...c.org>
Cc: Thiago Macieira <thiago@...ieira.org>,
Florian Weimer <fw@...eb.enyo.de>, libc-alpha@...rceware.org, musl@...ts.openwall.com,
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,
On Sun, Nov 02, 2025 at 07:28:57PM -0500, Rich Felker wrote:
> On Mon, Nov 03, 2025 at 12:58:39AM +0100, Alejandro Colomar wrote:
> > > All this will need fine-tuning once implementations exist.
> > >
> > > > So, why not require the caller to not ask too much? We could go back to
> > > > reporting an error if there's not enough memory.
> > > >
> > > > Of course, it would still guarantee no errors when shrinking, but
> > > > I think we could error out when growing.
> > >
> > > I'd prefer no errors either way. If there isn't memory to grow the underlying
> > > space (a brk() system call returns ENOMEM), then realloci() returns as much as
> > > it could get but not more.
> >
> > The problem is that this is asking the implementation to speculate.
> >
> > Consider the case that a realloci() implementation knows that the
> > requested size fails. Let's put some arbitrary numbers:
> >
> > old_size = 10000;
> > requested_size = 30000;
> >
> > It knows the block can grow to somewhere between 10000 (which it
> > currently has) and 30000 (the system reported ENOMEM), but now it has
> > the task of allocating as much as it can get. Should it do a binary
> > search of the size? Try 20000, then if it fails try 15000, etc.?
> > That's speculation, and it would make this function too slow.
>
> I don't see any plausible implementation in which this involved a
> binary search. Either you have fixed-size slots in which case you just
> look at the size of the slot to see what the max obtainable is, or you
> have a dlmalloc-like situation where you check the size of the
> adjacent free block (if any) to determine the max obtainable. These
> are O(1) operations.
I was thinking of mremap(2) without MREMAP_MAYMOVE.
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.
