[Bug 45] Bug in conversion of floating point literals

[d-bugmail at puremagic.com]

http://d.puremagic.com/bugzilla/show_bug.cgi?id=45





------- Comment #2 from clugdbug at yahoo.com.au  2006-03-15 06:12 -------
> Strictly speaking the code above behaves correctly.
> 
> http://www.digitalmars.com/d/float.html
> # For floating point operations and expression intermediate values, a
> # greater precision can be used than the type of the expression. Only the
> # minimum precision is set by the types of the operands, not the maximum. 
> 
> The documentation doesn't require an expression to always use the same
> "excessive" precision.

That doesn't apply in this case. There's no intermediate value here.

3.40483L is not the same as 3.40483. It's a different number.

You provide the compiler with input values of a given precision, and it returns
output values of a different precision. It's free to use any higher precision
during the intermediate calculations, but it is NOT free to change the
precision of the inputs (if it were, the L prefix would be entirely
meaningless). It's just a bug (and I suspect it's a regression introduced
during the improvements to constant folding that occurred around DMD 0.138).


--