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/>
signature.asc
Description: PGP signature
