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

[Jim Meyering]

Bruno Haible <address@hidden> wrote:

> 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.

Thanks to both of you,
However, neither works.  With the latter, it's because this expression
0.1L == (long double) 0.1
evaluates to true.