PATCH: Relax one test in 18_support/numeric_limits.cc for FreeBSD only

[Loren James Rittle]

In article <3C468D9C.2040408@unitus.it> you write:
> Loren James Rittle wrote:

>>+ // they were wrong verses the actual FP hardware.

> Versus?

The limits as expressed in /usr/include/float.h on FreeBSD for long
double are exactly as those expressed for double.  Double uses a/the
standard 8-byte IEEE FP format (I don't know the full official name).
In fact, here is the excerpt from that system header:

#define LDBL_MANT_DIG   DBL_MANT_DIG
#define LDBL_EPSILON    DBL_EPSILON
#define LDBL_DIG        DBL_DIG
#define LDBL_MIN_EXP    DBL_MIN_EXP
#define LDBL_MIN        DBL_MIN
#define LDBL_MIN_10_EXP DBL_MIN_10_EXP
#define LDBL_MAX_EXP    DBL_MAX_EXP
#define LDBL_MAX        DBL_MAX
#define LDBL_MAX_10_EXP DBL_MAX_10_EXP

Yet the precision seen on i386 hardware with gcc on this OS for long
double is greater than allowed by the 8-byte format without extending
the range at all (since this is done in a generic OS header, the same
mapping is done on FreeBSD/alpha and all other CPUs supported by
FreeBSD).  Perhaps due to a long-ago mistake or "feature", the ABI for
a long double is 12 bytes.

This program:

main() {printf ("%d\n", sizeof (long double));}

as compiled with the system compiler (also gcc but not 3.0 with
libstdc++-v3):

$ a.out
12

as compiled with gcc 3.1 (prerelease) from FSF sources:

$ a.out
12

So it is "system header declaration of limits for long double" verses
"startup code for port on CPU and implied actual precision limits for
long double".  The bug, if anywhere, is in an operating system
header's expression since the ABI clearly allocates 12 bytes and they
are productively used (not really supported very well by the library
implementation according to man pages) beyond the 8-byte format.  But
it is not the type of bug that may be simply fixed with a fixinclude
rule or by making the C++ limits != C limits.  Users of the operating
system header, employing the standard idioms of FP use will not even
notice the mismatch.

Regards,
Loren