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

[Bruno Haible]

Paul Eggert wrote:
> How about checking for this via a compile-time test?  That way we don't
> need to maintain a list of which software systems have the bug.

Yes, thanks. I wouldn't want to explicitly distinguish FreeBSD 6.1 and 6.2
in an autoconf test.

> --- a/lib/float.in.h
> +++ b/lib/float.in.h
> @@ -24,7 +24,6 @@
>  #define _GL_FLOAT_H
> 
>  /* 'long double' properties.  */
> -#if defined __i386__ && defined __BEOS__

I would keep the __i386__ in. The 'long double' types on MIPS and PowerPC
definitely work in different ways; I don't understand how they work and what
are the right <float.h> macro values for these processors.

> --- a/m4/float_h.m4
> +++ b/m4/float_h.m4
> ...
> +      int check_LDBL_MANT_DIG[
> +        (! (FLT_RADIX == 2
> +            && DBL_MANT_DIG == 53
> +            && (0.1L - 0.1
> +                == -5.5497598704101758215756490244530141353607177734375e-18L)
> +            && LDBL_MANT_DIG != 64)
> +         ? 1 : -1)

This is too risky in my opinion. This test is not betting on
  1) the compiler's ability to evaluate floating-point expressions at compile-
     time correctly (something that gcc as a cross-compiler didn't have
     before GCC 3.0 or so),
  2) but also on the correct decimal-to-binary conversion in the compiler.

How about this?

      int check_LDBL_MANT_DIG[
        2 * (LDBL_MANT_DIG != DBL_MANT_DIG || 0.1L == (long double) 0.1) - 1];

It only checks whether, if <float.h> says that 'double' and 'long double'
have the same precision, the compiler's representation of 0.1L has the
same precision as 0.1.

Bruno