Newsgroups: comp.os.msdos.djgpp
From: design AT netcom DOT com (Chris Waters)
Subject: Re: Problems with DJGPP V2.01 - atof() function
Message-ID: <designE1rt5L.Jo2@netcom.com>
Organization: Design and Delivery
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>
Date: Mon, 2 Dec 1996 05:12:57 GMT
Lines: 15
Sender: design AT netcom22 DOT netcom DOT com
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

In article <32A18E63 DOT 3F09 AT pobox DOT oleane DOT com>,
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.  That could easily explain the behavior you're seeing, if the
round-to-nearest requires rounding up.  Truncation only happens when the
float/double is converted to an int.  The best solution is to always add
0.5 before converting any float or double to an int, as someone
suggested already.