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