Re: "seq .1 .1" would mistakenly generate no output on FreeBSD 6.1

[Bruno Haible]

Jim Meyering pushed for a quick resolution:
> I'm hoping to make a coreutils test release RSN,
> and one of the few things missing is the macro to help
> work around the freebsd 6.1 long double printf bug.

Your test proggie results revealed that the bug is that although
'long double' generally has 53 bits of precision (in compile-time
expressions, in <float.h>, and in some run-time computations), it sometimes
has 64 bits of precision (in some other run-time computations). To me,
that counts as "excess precision".

I planned to conditionally disable the check in vasnprintf.c; but I don't
have much time right now and you are pushing, so I disable it unconditionally.


2007-11-26  Bruno Haible  <address@hidden>

        * lib/vasnprintf.c (decode_long_double): Don't abort if the
        'long double' type has excess precision.
        Reported by Jim Meyering in
        <http://lists.gnu.org/archive/html/bug-gnulib/2007-11/msg00120.html>.

--- lib/vasnprintf.c
+++ lib/vasnprintf.c
@@ -871,8 +871,11 @@ decode_long_double (long double x, int *ep, mpn_t *mp)
        abort ();
       m.limbs[--i] = (hi << (GMP_LIMB_BITS / 2)) | lo;
     }
+#if 0 /* On FreeBSD 6.1/x86, 'long double' numbers sometimes have excess
+         precision.  */
   if (!(y == 0.0L))
     abort ();
+#endif
   /* Normalise.  */
   while (m.nlimbs > 0 && m.limbs[m.nlimbs - 1] == 0)
     m.nlimbs--;