Date: 11 Aug 2003 07:53:19 +0200
Message-Id: <uu18osptc.fsf@elta.co.il>
From: Eli Zaretskii <eliz AT elta DOT co DOT il>
To: djgpp-workers AT delorie DOT com
In-reply-to: <200308102312.h7ANC6mQ021365@envy.delorie.com> (message from DJ
	Delorie on Sun, 10 Aug 2003 19:12:06 -0400)
Subject: Re: Anomaly in printf()
References: <1e0 DOT eca6e87 DOT 2c67e363 AT aol DOT com> <200308101817 DOT h7AIHDhr019129 AT envy DOT delorie DOT com> <9003-Sun10Aug2003222306+0300-eliz AT elta DOT co DOT il> <200308102312 DOT h7ANC6mQ021365 AT envy DOT delorie DOT com>
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> Date: Sun, 10 Aug 2003 19:12:06 -0400
> From: DJ Delorie <dj AT delorie DOT com>
> 
> > Is it?  We are printing a long double, which IIRC has 19 significant
> > digits.  The ``error'' here happens in the 20th digit, unless I'm
> > mistaken.
> 
> Long doubles have 64 bits of mantissa, with a separate sign.  We
> should have no problems representing, and thus printing, 2**64-2.

In a long double, the mantissa includes the integer bit, unlike in a
float or a double.  Se we lose one bit.

> The fact that Linux can get it right means that the format can
> represent the numbers just fine.

AFAIU, the format is not the issue here.  We are discussing the string
of digit characters that is produced by printing the numbers.  (I'd be
interested in seeing the actual bit patterns of the numbers as shown
by a debugger; I'm quite sure these bit patterns are okay.)  Since
_doprnt does some amount of math on its argument, loss of precision
beyond the significant digits is inevitable.  One should expect
singular failures like that.

(Btw, I have a vague recollection we already had this discussion in
the past, with this same example.)