standards/130067: Wrong numeric limits in system headers?

[John Hein]

The following reply was made to PR standards/130067; it has been noted by GNATS.

From: John Hein <jhein at timing.com>
To: =?UTF-8?B?VsOhY2xhdiBIYWlzbWFu?= <v.haisman at sh.cvut.cz>
Cc: Bruce Evans <brde at optusnet.com.au>, das at FreeBSD.ORG, imp at FreeBSD.ORG,
        freebsd-gnats-submit at FreeBSD.ORG, freebsd-standards at FreeBSD.ORG
Subject: Re: standards/130067: Wrong numeric limits in system headers?
Date: Fri, 9 Jan 2009 08:57:26 -0700

 V=E1clav Haisman wrote at 22:56 +0100 on Jan  8, 2009:
  > David Schultz wrote, On 6.1.2009 20:03:
  > > On FreeBSD/i386, long doubles are represented with 64 bits of
  > > precision, but computations are performed with 53 bits of
  > > precision. In a sane world, this discrepancy wouldn't exist, but
  > > for reasons I won't get into, they do, and probably always will.
  > > =
 
  > > C99 defines the LDBL constants based on what can be represented,
  > > not what can be computed as the result of arithmetic operations,
  > > so my interpretation is that the values in float.h are correct,
  > > though confusing.
  > I am not language lawyer but even if it were true that the constants a=
 re
  > right, there is still the problem that they (especially the LDBL_MAX v=
 alue)
  > are useless with the provided GCC. Either GCC or the headers should be=
 
  > changed. Otherwise the constants are rather useless and unusable.
 
 FWIW, when you compile the OP's sample code on i386 with -pedantic
 (with 6.x's base gcc 3.4.6 or 7.x's base gcc 4.2.1), you get:
 
 x.cc:11: error: floating constant exceeds range of 'long double'
 
 (the LDBL_MAX line)
 
 That seems to tip the scale more to the 'float.h is wrong' side.