[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: *alloc-gnu on glibc

From: Paul Eggert
Subject: Re: *alloc-gnu on glibc
Date: Sat, 15 May 2021 10:36:39 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]