Re: *alloc-gnu on glibc

From: Bruno Haible <bruno@clisp.org>
To: "Pádraig Brady" <P@draigbrady.com>
Cc: bug-gnulib@gnu.org
Subject: Re: *alloc-gnu on glibc
Date: Sat, 15 May 2021 17:49:37 +0200	[thread overview]
Message-ID: <5117514.Aj2YGekx1L@omega> (raw)
In-Reply-To: <c12fffa9-cc0d-2470-0a5c-3e05fe93408d@draigBrady.com>

Hi Pádraig,

> On glibc-2.31-5.fc32.x86_64 I'm seeing this test failure with coreutils,
> since the tests are now checking for a specific errno.
> I just checked a later Fedora 34 system which has the same issue.

For me, a testdir created through

   ./gnulib-tool --create-testdir --dir=../testdir --single-configure \
                  malloc-gnu realloc-gnu calloc-gnu reallocarray

passes all tests on Fedora 32 (glibc 2.31) and Fedora 33 (glibc 2.32).

> Specifically test-realloc-gnu is enabled in coreutils
> and it's failing as realloc is returning NULL as expected, but errno is 0.
> Specifically on glibc realloc(NULL, PTRDIFF_MAX+1) does return 0,errno=ENOMEM,
> but realloc(non_null, PTRDIFF_MAX+1) returns 0,errno=0.

POSIX <https://pubs.opengroup.org/onlinepubs/9699919799/functions/realloc.html>
says two things:

  1) By enumerating the error values, it implies that when realloc() fails,
     errno gets set to an error number. See
     <https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_03>
  2) "If there is not enough available memory, realloc() shall return a null
      pointer and set errno to [ENOMEM]."

If realloc() is failing but does not set errno, or sets errno to 0, that's a
POSIX violation. To be reported in the glibc bugzilla.

If realloc() is failing and sets errno to some value != ENOMEM, that is
technically valid (since you can debate which is the "cause" of the failure
and which errno value provides the best information). Personally I think
that
  - for an argument > PTRDIFF_MAX, EOVERFLOW is a reasonable error code,
  - EAGAIN is not a good error code, since "Out of memory" is a better error
    message than "Resource temporarily unavailable".

> In any case I'd be in favor of relaxing the test,

I'm in favour of reporting the POSIX violation in the first place.

> some notes on solaris below...
> ...
> but I did check the code in isolation on a 64 bit solaris 10 system.
> ...
> The following shows that it's important to ensure the compiler
> is explicitly running in 64 bit mode, as the default is 32 bit,

My knowledge about how to invoke the compiler is here:
https://gitlab.com/ghwiki/gnow-how/-/wikis/Platforms/Configuration
If you think some of the table entries are wrong, please say so.

> Both the above returned immediately for me.

Solaris 11 apparently behaves differently than Solaris 10.

Bruno