[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: *alloc-gnu on glibc
From: |
Bruno Haible |
Subject: |
Re: *alloc-gnu on glibc |
Date: |
Sat, 15 May 2021 17:49:37 +0200 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-206-generic; KDE/5.18.0; x86_64; ; ) |
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