[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87y0op1uoy.fsf@gmail.com>
Date: Sat, 01 Nov 2025 11:20:13 -0700
From: Collin Funk <collin.funk1@...il.com>
To: Rich Felker <dalias@...c.org>
Cc: Alejandro Colomar <alx@...nel.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>,
Thiago Macieira <thiago@...ieira.org>
Subject: Re: Re: realloci(): A realloc() variant that works in-place
Rich Felker <dalias@...c.org> writes:
>> 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.
ptrdiff_t probably makes more sense for allocation sizes anyways.
Collin
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.
