[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m1zf989d44.fsf@gmail.com>
Date: Thu, 30 Oct 2025 16:35:55 -0700
From: Collin Funk <collin.funk1@...il.com>
To: "A. Wilcox" <AWilcox@...cox-Tech.com>
Cc: musl@...ts.openwall.com, libc-alpha@...rceware.org, Arthur O'Dwyer
<arthur.j.odwyer@...il.com>, Jonathan Wakely <jwakely@...hat.com>,
Thiago Macieira <thiago@...ieira.org>
Subject: Re: realloci(): A realloc() variant that works in-place
"A. Wilcox" <AWilcox@...cox-Tech.com> writes:
>> - We could perfectly return int (0 for success, -1 for error),
>> but returning the pointer makes it a drop-in replacement for
>> realloc(3), and also allows using it in chained code
>>
>> foo(realloci(p, size));
>
>
> This is never safe if `realloci` can return `NULL`, IMO.
This was my concern as well. The code looks nicer than a normal realloc,
but I think it will lead to more people not checking for allocation
failures. I would rather have a nice error message than a segmentation
fault when a program fails to allocate memory.
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.
