GNU bug report logs - #9612
sort: avoid a NaN-induced infloop

Previous Next

Package: coreutils;

Reported by: Jim Meyering <jim <at> meyering.net>

Date: Tue, 27 Sep 2011 14:50:02 UTC

Severity: normal

Done: Jim Meyering <jim <at> meyering.net>

Bug is archived. No further changes may be made.

Full log


Message #20 received at 9612 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Andreas Schwab <schwab <at> linux-m68k.org>, 9612 <at> debbugs.gnu.org
Subject: Re: bug#9612: sort: avoid a NaN-induced infloop
Date: Tue, 27 Sep 2011 22:32:54 +0200
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.




This bug report was last modified 13 years and 229 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.