Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <16903de7-8340-4178-8b0b-2c4651f981a3@app.fastmail.com>
Date: Mon, 10 Nov 2025 09:51:10 -0500
From: "Zack Weinberg" <zack@...folio.org>
To: "Paul Eggert" <eggert@...ucla.edu>
Cc: "GNU libc development" <libc-alpha@...rceware.org>,
 musl@...ts.openwall.com
Subject: Re: Re: realloci(): A realloc() variant that works in-place

On Sun, Nov 9, 2025, at 9:47 PM, Paul Eggert wrote:
> On 2025-11-09 17:20, Rich Felker wrote:
>> The only way the lifetime of P does not end is if realloc returns a
>> null pointer indicating failure.
>
> Yes, and my point was that Alejandro's summary of the situation (which
> you went along with) got this detail wrong. And once one gets this
> detail right (which static analyzers of course can do), that
> discredits the idea that static analyzers are so dumb that they can't
> handle conditional results from functions like realloc. On the
> contrary, static analyzers do that sort of thing routinely, and they
> could continue to do so if the standard were changed slightly in the
> direction I proposed.

I've been trying to stay out of this argument, but I'm fed up with how
circular it's gotten.

Paul: Your proposed change to the C standard is never, ever going to
happen.  It's exactly the same situation as the pointer aliasing rules:
The wording you don't like has been there since C1989. People have been
complaining about it since 1991 or so.  The C committee cannot help but
be aware of the complaints.  They have repeatedly chosen to take no
action on those complaints.  The logical conclusion is that the standard
says what the committee wants it to say and further complaining is
futile.  Please drop this line of argument.

In addition, it has been repeatedly explained that the C++ use cases for
realloci() require a function whose _contract_ is that it will never
move the block to be resized; a standard-licensed mechanism for fixing
up pointers inside a moved block is _not good enough_ for C++. (We're
never going to get that mechanism either, but it's _moot_ in this case!)
So please drop that line of argument as well.

zw

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.