Nope. It is only when a constant is generated. Judging from a e-mail that I received
from a metrowerks employee it may be in more
than just division.
They seem to be quite responsive about this. Hopefully the fix will be available soon.
Rick Wagner
> -----Original Message-----
> From: Michael Yam [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, April 13, 1999 12:07 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Serious brand-new FP bug in CW 5.1
>
>
> Would you know if this is also a problem for the Flpxxxx()
> routines, that is
> something along the lines of:
>
> FlpDouble a, b;
>
> _d_div (a, b);
>
> I would try it myself but haven't downloaded the CW 5.1.
>
> Michael Yam
> Y Technology, Inc.
> [EMAIL PROTECTED]
>
> -----Original Message-----
> From: Richard Wagner <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>;
> [EMAIL PROTECTED]
> <[EMAIL PROTECTED]>
> Date: Monday, April 12, 1999 6:04 PM
> Subject: Serious brand-new FP bug in CW 5.1
>
>
> This code:
> double dTemp;
> dTemp = 10000.0/207.0;
>
> actually assigns the value of .0207 to dTemp. What's wrong
> with that? Well
> look again, the stupid compiler REVERSED the operator order!
> Instead of
> dividing 10000 by 207 it divided 207 by 10000!
>
> This is 100% reproducable for me in multiple projects using
> both the PalmOS
> FP library and the linkable library (which shouldn't make a difference
> anyway). This has only been tried under CW 5.1 for Windows.
> Same stuff
> worked great under CW 5.0 for Windows. I've also tried no
> optimizations as
> well as maximum optimizations, no difference.
>
> And in case you're curious in Codewarrior (207.0/10000.0) = 48.x!
>
> I haven't played around to see if this applies to anything other than
> doubles since CW 5.1 has already wasted an entire day
> debugging. Grrrr....
>
>
>
>
>
