[Issue 13420] double.nan unusable as AA key

via Digitalmars-d-bugs digitalmars-d-bugs at puremagic.com
Fri Sep 19 11:54:02 PDT 2014


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

Steven Schveighoffer <schveiguy at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy at yahoo.com

--- Comment #7 from Steven Schveighoffer <schveiguy at yahoo.com> ---
(In reply to Vladimir Panteleev from comment #6)
> Maybe the AA implementation should assert that keys added to it should be
> equal to themselves. That would make the problem easier to spot, at least
> (in my case it caused the output to be incorrect).

Yeah, possibly a good solution. But I think we should not pay the runtime
penalty for this rare situation (every access using every key type must be
checked). I actually think the current breakage of code is warranted, and this
is not going to cause a lot of problems (I would guess not many use nan keys).

Incidentally, typeid(float).compare is broken.

Observe:

    float a, b=1;                              // a = nan
    assert(!(a < b));                          // test 1
    assert(typeid(float).compare(&a, &b) < 0); // test 2

>From the definition of opCmp, this implies that from the result of test 1, test
2 should fail (compare(&a, &b) should be >= 0). In fact, I fully expected
compare(&a, &b) to be 0.

So your code only worked because:
a) the old AA implementation assumed compare(a, b) == 0 means equality (and as
has been discussed in the NG, this is not the case)
b) float.compare(x, y) can return -1 or 1 even when x or y is inf or nan!

I think we need another bug report for b)... (will add)

--


More information about the Digitalmars-d-bugs mailing list