[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9eb4aede-9cbe-4f7d-a60b-2693004daa56@cs.ucla.edu>
Date: Fri, 20 Jun 2025 20:50:07 -0700
From: Paul Eggert <eggert@...ucla.edu>
To: Alejandro Colomar <alx@...nel.org>
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
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.
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.
