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

via Digitalmars-d-bugs digitalmars-d-bugs at puremagic.com
Wed Sep 24 19:46:59 PDT 2014


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

Walter Bright <bugzilla at digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla at digitalmars.com

--- Comment #2 from Walter Bright <bugzilla at digitalmars.com> ---
Consider this C++ code:

  bool foo(long double a) { return a; }

DMC++ generates:

                fld     tbyte ptr 4[ESP]
                fldz
                fucompp ST(1),ST
                fstsw   AX
                sahf
                jne     L13
                jp      L13
                xor     EAX,EAX
                jmp short       L18
    L13:        mov     EAX,1
    L18:        ret

and g++ generates:

                fld     tbyte ptr 8[RSP]
                mov     EAX,1
                fldz
                fucomip
                fstp    ST
                setp    DL
                cmovz   EAX,DL
                ret

In other words, both of them treat NaN as "TRUE". I fear that if we deviate
from this behavior, we'll get subtly broken code that is written by former C++
programmers or that is transliterated from C++.

Having cast(bool)d yield different results than d!=0 to me is very surprising
behavior.

Having cast(bool)d rewritten to be d<>0 is also problematic as Don Clugston is
a vocal advocate of having the <> operator removed from D.

Issuing a warning or error for if(d) can be done, but then the user simply
rewrites it as if(d!=0) and I'm not sure if anything was accomplished.

So I'm not sure what the right answer would be.

I do strongly suggest that calculations that return money values have sanity
checks in them for reasonable dollar values; not just 0, Infinity or NaN
checks. An amount of 9 trillion dollars shouldn't have gotten far. Such checks
can find a great many more mistakes than NaNs would.

Another possibility is to not use lround(), i.e. make your own lround that
asserts that its argument is not NaN. Note that lround() in D just defers to
the C one, which is underspecified as to what happens with NaN or Infinity
arguments. I would not rely on C's lround() for financial calculations without
first checking its argument.

--


More information about the Digitalmars-d-bugs mailing list