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.

Reply via email to