Re: *alloc-gnu on glibc

[Paul Eggert]

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).