[Issue 13489] Boolean semantics of floating point types should use "<> 0"

via Digitalmars-d-bugs digitalmars-d-bugs at puremagic.com
Sat Oct 4 22:53:09 PDT 2014


https://issues.dlang.org/show_bug.cgi?id=13489

--- Comment #10 from Walter Bright <bugzilla at digitalmars.com> ---
(In reply to Leandro Lucarella from comment #9)
> (In reply to David Eckardt from comment #8)
> > My point is: NaN was intentionally chosen as the initial floating point
> > value to detect the common bug of forgetting to initialize a variable
> > (http://dlang.org/faq.html#nan). The standard way to detect bugs is a plain
> > assert(). So assert() should fail with NaN.
> 
> Yeah, this is the key, NaN should behave the same as null, it should explode
> as soon as it's used.

NaN is designed not to explode when used, but to propagate in that all
operations on NaN should yield NaN as a result. Changing this would be not only
a drastic change to the language, but would cause D to behave very differently
from every other language that deals with NaNs.

I propose instead that, here, the real problem is what lround() did with a NaN
value - it returned garbage. I suggest that you ban use of lround() from your
system and replace with one that asserts on NaN arguments.


> > (PS. Amounts like 80,833,756,980 Vietnamese Đồng do happen so limiting them
> > is far from trivial...)
> 
> Yeah, you should have to check the currency and maintain a table of
> conversion rates. Not a very promising approach ;-)

That's 80 billion, far short of the 9 trillion in the original error. It is
essential to have sanity checks on the results of critical calculations.

D2 has also recently added core.checkedint with functions in it to do overflow
checking addition, subtraction, multiplication and division. These are portable
to D1. They replace ad hoc methods that are often misguided or simply wrong.

--


More information about the Digitalmars-d-bugs mailing list