bug#6020: coreutils-8.x: a simple feature enhancement, and how to do it

[Pádraig Brady]

On 24/04/10 02:30, Nelson H. F. Beebe wrote:

[snipped very useful floating point info]

> At present, up to version 8.5, coreutils uses only type double in its
> implementation of the -g sort-ordering option.  The result is that it
> is unable to correctly sort files that use the entire number range of
> IEEE 754 binary arithmetic; indeed, the double format covers only
> about 6% of the possible binary range, and 5% of the decimal range.

This should do it.
Using long double has no impact on performance on my pentium-m linux laptop.
Note I tried converting to use xstrtold(), but that added about 25% overhead :(

diff --git a/src/sort.c b/src/sort.c
index 6d47b79..a815244 100644
--- a/src/sort.c
+++ b/src/sort.c
@@ -1855,10 +1855,16 @@ general_numcompare (const char *sa, const char *sb)
   /* FIXME: maybe add option to try expensive FP conversion
      only if A and B can't be compared more cheaply/accurately.  */

+#if HAVE_C99_STRTOLD /* provided by c-strtold module.  */
+# define STRTOD strtold
+#else
+# define STRTOD strtod
+#endif
+
   char *ea;
   char *eb;
-  double a = strtod (sa, &ea);
-  double b = strtod (sb, &eb);
+  long double a = STRTOD (sa, &ea);
+  long double b = STRTOD (sb, &eb);

   /* Put conversion errors at the start of the collating sequence.  */
   if (sa == ea)

> However, note that some aberrant systems implement "long double" as
> "double" (e.g., DEC Alpha OSF/1 4.x, Minix, and most *BSD
> distributions), and some implement it in doubled-double format, which
> increases the precision, but leaves the range at that of double.
> Examples of the latter include Apple Mac OS X on PowerPC, IBM AIX on
> PowerPC, and SGI IRIX MIPS.

I was wondering about a test for this:

$ printf "3.64e-4951\n3.63e-4950\n" | ./sort -g
3.64e-4951
3.63e-4950

However I'm worried that will fail because of what you mention above.
I probably need to add LDBL_{MIN,MAX} to getlimits.

cheers,
Pádraig.