bug#9612: sort: avoid a NaN-induced infloop

[Jim Meyering]

Paul Eggert wrote:
> On 09/27/11 13:07, Andreas Schwab wrote:
>> Padding bits can change any time.
>
> Is there any way to compare the non-padding parts of long doubles?
> There ought to be *some* way to get the fractional part of a NaN, no?
> For example, with glibc, is there some way to sprintf to a buffer
> and get the fraction out of the text in the buffer?

Good idea.

Since the problem may be glibc-specific the work-around can be, too.
/usr/include/ieee754.h defines this:

union ieee854_long_double
  {
    long double d;

    /* This is the IEEE 854 double-extended-precision format.  */
    struct
      {
#if     __BYTE_ORDER == __BIG_ENDIAN
        unsigned int negative:1;
        unsigned int exponent:15;
        unsigned int empty:16;
        unsigned int mantissa0:32;
        unsigned int mantissa1:32;
#endif
#if     __BYTE_ORDER == __LITTLE_ENDIAN
# if    __FLOAT_WORD_ORDER == __BIG_ENDIAN
        unsigned int exponent:15;
        unsigned int negative:1;
        unsigned int empty:16;
        unsigned int mantissa0:32;
        unsigned int mantissa1:32;
# else
        unsigned int mantissa1:32;
        unsigned int mantissa0:32;
        unsigned int exponent:15;
        unsigned int negative:1;
        unsigned int empty:16;
# endif
#endif
      } ieee;

      ...

I went ahead and committed my expedient patch,
with adjusted URL in the log.

I'm sure we'll get something better, though...

BTW, this was introduced between 8.5 and 8.6, and I'll update NEWS with that.
While I haven't found the specific commit, it's probably for this feature:

    * Noteworthy changes in release 8.6 (2010-10-15) [stable]
      sort -g now uses long doubles for greater range and precision.