[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250624130436.GN1827@brightrain.aerifal.cx>
Date: Tue, 24 Jun 2025 09:04:37 -0400
From: Rich Felker <dalias@...c.org>
To: Florian Weimer <fweimer@...hat.com>
Cc: Alejandro Colomar <alx@...nel.org>, libc-alpha@...rceware.org,
bug-gnulib@....org, musl@...ts.openwall.com,
наб <nabijaczleweli@...ijaczleweli.xyz>,
Douglas McIlroy <douglas.mcilroy@...tmouth.edu>,
Paul Eggert <eggert@...ucla.edu>,
Robert Seacord <rcseacord@...il.com>,
Elliott Hughes <enh@...gle.com>, Bruno Haible <bruno@...sp.org>,
JeanHeyd Meneide <phdofthehouse@...il.com>,
Adhemerval Zanella Netto <adhemerval.zanella@...aro.org>,
Joseph Myers <josmyers@...hat.com>,
Laurent Bercot <ska-dietlibc@...rnet.org>,
Andreas Schwab <schwab@...e.de>, Eric Blake <eblake@...hat.com>,
Vincent Lefevre <vincent@...c17.net>,
Mark Harris <mark.hsj@...il.com>,
Collin Funk <collin.funk1@...il.com>,
Wilco Dijkstra <Wilco.Dijkstra@....com>, DJ Delorie <dj@...hat.com>,
Cristian Rodríguez <cristian@...riguez.im>,
Siddhesh Poyarekar <siddhesh@...plt.org>,
Sam James <sam@...too.org>, Mark Wielaard <mark@...mp.org>,
"Maciej W. Rozycki" <macro@...hat.com>,
Martin Uecker <ma.uecker@...il.com>,
Christopher Bazley <chris.bazley.wg14@...il.com>,
eskil@...ession.se,
Daniel Krügler <daniel.kruegler@...glemail.com>,
Kees Cook <keescook@...omium.org>,
Valdis Klētnieks <valdis.kletnieks@...edu>
Subject: Re: Re: alx-0029r3 - Restore the traditional realloc(3)
specification
On Tue, Jun 24, 2025 at 11:07:53AM +0200, Florian Weimer wrote:
> * Alejandro Colomar:
>
> > Here's a new revision of the proposal. I've removed ENOMEM, since it's
> > not strictly necessary; it's only necessary that those systems that
> > already set it continue setting it (and my proposal for POSIX will
> > certainly include ENOMEM).
>
> As far as I can see, this changes specification across all allocation
> functions and requires them to be able to produce zero-sized objects.
> Previously, the discussion was about changing realloc only.
>
> Is this really the right direction, given that
>
> int a[n];
>
> is still undefined, and that C does not support zero-sized objects in
> general?
>
> Wouldn't it be more consistent to move in the other direction, and
> require that allocations of zero size fail because C does not support
> zero-sized objects?
>
> (This is why I don't want to make any changes today—we just don't know
> what the tightened specification will look like in the published
> standard. There are just too many totally reasonable variations.)
This is the change that pretty much nobody wants, except perhaps
ideologues out to inflict pain on users and implementors of the
language. It makes it harder to write correct code, requiring
special-casing of zero all over the place in addition to existing
essential difficulties for handlng overflow, and has no tangible
advantages. Even the ideological motivation is ill-posed, as the issue
of "no such thing as zero-sized objects" was solved *over 3 decades*
ago with the language in the standard (it's not a zero-sized object
but a pointer you can't dereference that compares non-equal to
others).
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.
