[dmd-beta] Struct Comparision WTF: Is the new or old behavior right?

[Jonathan M Davis]

On Friday, December 09, 2011 23:56:30 Walter Bright wrote:
> On 12/9/2011 10:36 PM, David Simcha wrote:
> > Using DMD 2.057 beta:
> > 
> > // test2.d:
> > import std.stdio;
> > 
> > struct S {
> > 
> >     double d;  // NaN
> > 
> > }
> > 
> > void main() {
> > 
> >     S s;
> >     writeln(s == S.init);
> > 
> > }
> > 
> > $ dmd test2.d -m32
> > $ ./test2
> > true
> > $ dmd test2.d -m64
> > $ ./test2
> > false
> > 
> > Somehow I think it's a bad idea to have the result of this comparison
> > change depending on whether you're compiling in 32- or 64-bit mode.  I
> > just spent a few hours debugging Plot2kill because this behavior
> > changed between releases in 64-bit mode, and I was comparing font
> > structs to their .init values to determine whether they had already
> > been initialized.  Everything worked in 32-bit mode but failed in
> > 64-bit mode.  In 64-bit mode it looked like the structs had already
> > been initialized (e.g. titleFont == Font.init is false) so they never
> > got initialized.  Needless to say, GTK does weird things when you pass
> > in a NaN as a font size.
> 
> The 32 bit code is wrong (please file a bug report). Comparisons should
> always yield false if one or both operands is a nan.

That makes it kind of ugly for init though, since it's often useful to check 
whether a value is equal to its type's init value. Treating NaN like this 
means that you can't do such equality checks if your type includes any floating 
point values - directly or indirectly. But it _would_ break the normal 
behavior of NaN to make init values act differently (and likely complicate the 
code generation a fair bit, since it would mean special casing init with 
regards to equality). So, I guess that it just means that you have to be 
careful when dealing with default-initialized floating point values.

Part of me thinks that NaN should be equal to NaN, but it's likely too late 
for that at this point, even if it were determined to be a good idea.

In any case, it's a bit funny to see a code generation error which is correct 
in 64-bit mode and incorrect in 32-bit mode. That's the reverse of what 
normally happens.

- Jonathan M Davis