On 5/15/21 9:04 AM, Pádraig Brady wrote:
I'm wondering should we be more relaxed here as,
there is only one standardised ENOMEM error from realloc,
so code doesn't have to behave differently based on what the errno is.
We've already relaxed the errno test for reallocarray, where NetBSD
fails with EOVERFLOW on ptrdiff_t overflow. (My own feeling is that
NetBSD is right and glibc is wrong here; perhaps I should file a glibc
bug report.)
The allocator modules are in some sense backwards. malloc-gnu requires
malloc-posix because GNU guarantees are a superset of POSIX guarantees.
And yet GNU programs often don't care about the POSIX guarantee of errno
being set, whereas some do care about the GNU guarantee that malloc
returns NULL only on failure.
Now I accept that error messages may be more accurate,
but one should opt into that I think.
That opt-in was what malloc-posix was supposed to be.
I see three options:
1. Make the realloc-gnu test more generous.
2. Fix realloc-posix to check for this glibc bug and replace realloc if
the test fails.
3. Complicate the set of Gnulib allocator modules so that apps can
more-accurately express their needs.
Although (3) is in some sense the "best" it's probably too complicated.
What we have is already too complicated. I'd rather have just malloc-gnu
and not worry about non-GNU behavior (that's the Gnulib way, right?).
(2) is surely the right way to go in the long run. The glibc behavior is
simply a bug.
In the short run I can see the temptation of (1).
