[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <osyp6rofuuldez7lt3endodgutz4q4vocz4brppnbgfvkawnc4@ked7kfjerblj>
Date: Sat, 21 Jun 2025 13:59:15 +0200
From: Alejandro Colomar <alx@...nel.org>
To: Paul Eggert <eggert@...ucla.edu>
Cc: Thorsten Glaser <tg@...bsd.de>, libc-alpha@...rceware.org,
bug-gnulib@....org, musl@...ts.openwall.com,
наб <nabijaczleweli@...ijaczleweli.xyz>, Douglas McIlroy <douglas.mcilroy@...tmouth.edu>,
Robert Seacord <rcseacord@...il.com>, Elliott Hughes <enh@...gle.com>, Bruno Haible <bruno@...sp.org>,
JeanHeyd Meneide <phdofthehouse@...il.com>, Rich Felker <dalias@...c.org>,
Adhemerval Zanella Netto <adhemerval.zanella@...aro.org>, Joseph Myers <josmyers@...hat.com>,
Florian Weimer <fweimer@...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
Subject: Re: alx-0029r1 - Restore the traditional realloc(3) specification
Hi Paul,
On Fri, Jun 20, 2025 at 08:50:07PM -0700, Paul Eggert wrote:
> On 2025-06-20 19:42, Alejandro Colomar wrote:
>
> > > If ENOMEM is really needed, its presence should be justified in the
> > > proposal.
> >
> > I wrote it, although maybe it would need to be clearer?
>
> It would need reworking as it didn't feel like a justification to me.
>
>
> > Here's the part that justifies it:
> >
> > Here's the code that should be written for AIX or glibc:
> >
> > errno = 0;
> > new = realloc(old, size);
> > if (new == NULL) {
> > if (errno == ENOMEM)
> > free(old);
> > goto fail;
> > }
> > ...
> > free(new);
> >
> > [...]
> >
> > If the realloc(3) specification was changed to require that
> > realloc(p,0) returns non-null on success, and that realloc(p,0)
> > only fails when out-of-memory, and to require that it sets
> > errno to ENOMEM, then code written for AIX or glibc would
> > continue working just fine, since the errno check would be
> > redundant with the null check. Simply, the conditional
> > (errno == ENOMEM) would always be true when (new == NULL).
> >
> > If that old code runs on a new system that doesn't set ENOMEM, it will
> > leak 'old'. Admittedly, that code is currently only portable to POSIX
> > systems, which already require ENOMEM, and I don't expect POSIX would
> > lift that requirement (and would recommend not lifting it), so I expect
> > people won't run that code in arbitrary C2y platforms.
>
> But this is exactly why the main proposal (i.e., null if-and-only-if
> failure) shouldn't require ENOMEM. The C standardizers have already thought
> through the ENOMEM issue and decided not to require ENOMEM. Whatever reasons
> they have, won't change because of the main proposal.
>
> ENOMEM belongs to POSIX, and POSIX will retain ENOMEM regardless of whether
> C2y accepts the main proposal. We shouldn't try to link the two proposals
> together in the C standardization process, as that's more likely to gum up
> the works entirely.
>
>
> > I added the ENOMEM part because of the above, to make sure that the new
> > realloc(3) specification is fully backwards compatible to every existing
> > implementation, so that you can take your AIX or glibc or musl or
> > whatever code, and say "hey, I'll run this code on any C2y-conforming
> > platform; it should Just Work".
>
> Those platforms are all POSIXish, and you'll be able to say "hey I'll run
> this code on any POSIX-202y system (which extends C2y) and it should Just
> Work". That's all anyone can reasonably expect. One can't reasonably expect
> to run a POSIXish program on any C2y system and let's not try to make that a
> goal.
Hmmmm, sounds reasonable. I'll have both options available in the
proposal, and let the C Committee decide if they want to add ENOMEM,
without blocking the proposal by ENOMEM.
Have a lovely day!
Alex
--
<https://www.alejandro-colomar.es/>
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
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.
