Message-ID: <32A2E10A.53F2@pobox.oleane.com>
Date: Mon, 02 Dec 1996 15:00:42 +0100
From: Francois Charton <deef AT pobox DOT oleane DOT com>
Organization: CCMSA
MIME-Version: 1.0
To: Chris Waters <design AT netcom DOT com>
CC: djgpp AT delorie DOT com
Subject: Re: Problems with DJGPP V2.01 - atof() function
References: <329e68a5 DOT 10316617 AT news DOT ua DOT pt> <32A02DD1 DOT 1157 AT pobox DOT oleane DOT com> <Pine DOT SOL DOT 3 DOT 91 DOT 961201085145 DOT 18913B-100000 AT aten> <32A18E63 DOT 3F09 AT pobox DOT oleane DOT com> <designE1rt5L DOT Jo2 AT netcom DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Chris Waters wrote:
> 
> Francois Charton  <deef AT pobox DOT oleane DOT com> wrote:
> 
> >This is quite interesting : the "more precise" 80bit number, or the cast
> >to double gives the wrong answer (mathematically I mean), whilst the
> >"rough" float truncate yields the right one... (And the truncated number
> >is bigger than the "less truncated" one: this is not what could be
> >expected from a truncature operation on a positive number).
> 
> Double to float involves round-to-nearest, rather than truncation, I'll
> bet. 

In the source compiled by DJGPP; this was handled by the two FPU 
instructions:
 fstps -12(%ebp)
 flds -12(%ebp)

so this seems to be quite machine dependent (I wonder what the emulator 
would yield...)

Francois