bug#78985: sort-float failure on ppc64, LDBL_MIN fraction part too long for test command to parse

[C. Neidahl]

I have a set of patches that resulted from a gnulib thread [1], which affect the values of some compiler definitions for the IBM long double format on powerpc64. Applying these to the vendored copy of gnulib in the coreutils 9.7 release tarball is necessary to fix a failure in the gnulib test suite.

--- exp 2025-07-09 14:38:32.521404281 +0000
+++ out 2025-07-09 14:38:32.551404251 +0000
@@ -2,11 +2,11 @@
 -1.7976931348623157e+308
 -3.4028235e+38
 -1.1754944e-38
--2.225073858507201383090232717332e-308
 -2.2250738585072014e-308
+-2.225073858507201383090232717332e-308
 0
-2.2250738585072014e-308
 2.225073858507201383090232717332e-308
+2.2250738585072014e-308
 1.1754944e-38
 3.4028235e+38
 1.7976931348623157e+308
./tests/sort/

--- exp 2025-07-09 14:38:32.571404231 +0000
+++ out 2025-07-09 14:38:32.601404202 +0000
[same list of values as above]
FAIL tests/sort/sort-float.sh (exit status: 1)





- Cosima

[1] https://lists.gnu.org/archive/html/bug-gnulib/2025-07/msg00021.html

These patches are resulting in a failure of the sort-float test from the coreutils test suite, with the following output: ./tests/sort/sort-float.sh: line 49: test: 225073858507201383090232717332: integer expression expected sort-float.sh: line 58: warning: setlocale: LC_ALL: cannot change locale (none): No such file or directory The issue seems to be that one of the test calls in the dbl_minima_order function is failing due to the fractional part of LDBL_MIN on this platform being too long for the test command to parse as an integer, so the call fails and the function incorrectly determines that DBL_MIN is smaller. This test call would in theory also fail before the set of gnulib patches, but the exponent-testing call gives a result first, so it never got that far on this platform before.

publickey - opna2608@protonmail.com - 0xC802C863.asc
Description: application/pgp-keys

signature.asc
Description: OpenPGP digital signature