From owner-freebsd-standards@FreeBSD.ORG Tue Jan 6 19:23:03 2009 Return-Path: Delivered-To: freebsd-standards@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E922106564A; Tue, 6 Jan 2009 19:23:03 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id CFF768FC12; Tue, 6 Jan 2009 19:23:02 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.3/8.14.2) with ESMTP id n06J3EjU015283; Tue, 6 Jan 2009 14:03:14 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.3/8.14.2/Submit) id n06J3DXq015282; Tue, 6 Jan 2009 14:03:13 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Tue, 6 Jan 2009 14:03:13 -0500 From: David Schultz To: Bruce Evans Message-ID: <20090106190313.GA15233@zim.MIT.EDU> Mail-Followup-To: Bruce Evans , Vaclav Haisman , imp@FreeBSD.ORG, freebsd-gnats-submit@FreeBSD.ORG, freebsd-standards@FreeBSD.ORG References: <200812302231.mBUMVUtf092910@www.freebsd.org> <20081231215445.S3923@delplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081231215445.S3923@delplex.bde.org> Cc: freebsd-standards@FreeBSD.ORG, Vaclav Haisman , imp@FreeBSD.ORG, freebsd-gnats-submit@FreeBSD.ORG Subject: Re: standards/130067: Wrong numeric limits in system headers? X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2009 19:23:03 -0000 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.