http://d.puremagic.com/issues/show_bug.cgi?id=8530


Don <clugd...@yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugd...@yahoo.com.au


--- Comment #3 from Don <clugd...@yahoo.com.au> 2012-08-15 06:23:41 PDT ---
(In reply to comment #2)
> (In reply to comment #1)
> > If you want to check for NaN, then use std.math.isNaN. As I understand it,
> > there is no guarantee that two NaN values have the same bit pattern (at
> > minimum, you have signed and unsigned NaN, and there may be more variations 
> > - I
> > don't remember). isNaN returns true in both cases. So, I don't believe that
> > this is a bug.
> 
> Thanks for your reply. However I still think it is a bug, because when I 
> assign
> TYPE.init to variable VAR of type TYPE, and then I compare VAR is TYPE.init, I
> assumed it returns true;

Your assumption is not correct. If type.init is a signalling NaN, the bit
pattern changes when you access it. It has nothing to do with classes.

More generally,

x = y;
assert (x is y);

Fails if x is floating point and y is a signalling NaN.
When reading from x, the 'quiet' bit of will be set, so that it reads a quiet
NaN, not a signalling one.
That's the way the hardware works, the same behaviour applies in any language
that uses the hardware.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

Reply via email to