On 09/09/2026 06:03, Collin Funk wrote:
On GNU/Hurd, error numbers are duplicated like this:$ ./src/getlimits | grep '^EPERM' EPERM='Operation not permitted' EPERM='(os/kern) invalid address' EPERM='(ipc/rcv) receive in progress' EPERM='(ipc/send) send in progress' When evaluating, the last one overrides the first one which is the one we care about in the test suite. For example, we see test errors like this because of this: + diff -u exp out --- exp 2026-09-09 06:01:03.000000000 +0100 +++ out 2026-09-09 06:01:03.000000000 +0100 @@ -1 +1 @@ -chgrp: 'd/no-x': (ipc/send) no msg buffer +chgrp: 'd/no-x': Permission denied + fail=1 I have attached 2 patches which should each solve the issue independently. I'm leaning towards the second one since it is the least invasive. It simply ignores the error strings with these prefixes, since they seem to be internal Mach stuff we don't care about: $ ./src/getlimits | grep -Eo '\(.*\)' | sort | uniq -c 12 (ipc/rcv) 16 (ipc/send) 26 (os/kern) The first one is tempting since it isn't platform specific, but it is probably best to avoid the small chance of it causing issues. Collin
That looks like Hurd's strerrorname_np() doesn't handle the for different errno spaces, thus returning the same value for EPERM and EKERN_INVALID_ADDRESS etc. E.g. see: https://sourceware.org/bugzilla/show_bug.cgi?id=29545 I wonder should gnulib's errno_iterate() be including these hurd kernel errors since they're in a different space? I suppose on hurd getlimits could filter in print_errno() wtih err_get_system(e)==err_hurd, but really we should be detecting/handling this in gnulib. Given this is lower priority and might be worked around with a gl_cv_func_strerrorname_np_works=no (or maybe the other way around), I'd be inclined to leave as is for the current release, and it can be adjusted in gnulib later. cheers, Padraig
