Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f1371cdd-cce6-ea4d-a6df-276ae645a56d@mirbsd.de>
Date: Sat, 1 Nov 2025 20:38:20 +0100 (CET)
From: Thorsten Glaser <tg@...bsd.de>
To: musl@...ts.openwall.com
cc: libc-alpha@...rceware.org, Arthur O'Dwyer <arthur.j.odwyer@...il.com>, 
    Jonathan Wakely <jwakely@...hat.com>, 
    Thiago Macieira <thiago@...ieira.org>
Subject: Re: Re: realloci(): A realloc() variant that works in-place

On Sat, 1 Nov 2025, Laurent Bercot wrote:

>> Where realloci() allocates at least 'size' bytes (but possibly more),
>> and returns the actual usable size of the block.
>
> If you're set on doing something like this, it would be simpler to
> provide a function that just returns the usable size of the block,
> under which realloc() is guaranteed not to relocate the object, and
> above which it is guaranteed to relocate.

The size of that block may depend on the size requested (and possibly
the availability at the time of requesting), so… no, not really simpler.

bye,
//mirabilos
-- 
When he found out that the m68k port was in a pretty bad shape, he did
not, like many before him, shrug and move on; instead, he took it upon
himself to start compiling things, just so he could compile his shell.
How's that for dedication. -- Wouter, about my Debian/m68k revival

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.