[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251101181017.GU1827@brightrain.aerifal.cx>
Date: Sat, 1 Nov 2025 14:10:17 -0400
From: Rich Felker <dalias@...c.org>
To: Alejandro Colomar <alx@...nel.org>
Cc: 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>,
Thiago Macieira <thiago@...ieira.org>
Subject: Re: Re: realloci(): A realloc() variant that works in-place
On Sat, Nov 01, 2025 at 04:22:30PM +0100, Alejandro Colomar wrote:
> Hi Florian,
>
> On Sat, Nov 01, 2025 at 02:05:57PM +0100, Florian Weimer wrote:
> > * Alejandro Colomar:
> >
> > > A discussion within the C++ std-proposals@ mailing list triggered the
> > > discussion about the need for a realloc() variant that works in-place,
> > > that is, that doesn't move the address of the memory, and thus that
> > > doesn't invalidate existing pointers derived from it.
> >
> > > void *realloci(void *p, size_t size);
> >
> > The caller won't have sufficient information to determine good values
> > for size.
> >
> > For the std::vector case at least, what applications want is some form
> > of non-moving realloc that allows the application to specify an
> > arithmetic progression and an interval, and the realloc variant should
> > change the size of the allocation to an element of the arithmetic
> > progression that resides within the specified interval, or fail.
>
> Would this work?:
>
> ssize_t realloci(void *p, size_t size);
>
> Where realloci() allocates at least 'size' bytes (but possibly more),
> and returns the actual usable size of the block. So, you could
>
> realloci(p, 3000);
>
> and it would return for example 4096, which would be the usable size of
> the block. Or it would return -1 if it is unable to grow that much.
> realloci() would never fail when shrinking, as it could just return a
> larger size and be done with it.
ssize_t is POSIX-only and unlikely to be adopted by C standard. It
could return (size_t)-1 instead.
Actually returning a value larger than n seems bad (makes it
impossible to detect OOB writes beyond the actually requested size)
though so this seems like a dubious feature.
Rich
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.
