Bruno Haible <[EMAIL PROTECTED]> 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.
