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


jens.k.mueller@gmx.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jens.k.mueller@gmx.de


--- Comment #20 from jens.k.mueller@gmx.de 2012-10-24 14:18:31 PDT ---
(In reply to comment #1)
> Arrays don't have a an opEquals overloaded operator. What's the bug?

I don't understand.
How can arrays have no opEquals yet this

assert(bar.data == foo.data);

compiles?
Syntactically there is opEquals and it checks whether each element is equal to
the corresponding other element.

And the opEquals generated by default should for each member call opEquals if
it exists. Otherwise it falls back to bit-wise equality.
Why should it be different from this?

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

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


Jonathan M Davis <jmdavisProg@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg@gmx.com


--- Comment #21 from Jonathan M Davis <jmdavisProg@gmx.com> 2012-10-27 19:52:35 PDT ---
I just thought that I should point out that the correct behavior for comparing structs is explained in section of 7.1.5.2 of TDPL (p. 258 - 259). It doesn't explicitly discuss what happens with built-ins (it says that opEquals is called on each of the members), but I would think that calling opEquals on each of the members would mean using == on built-in types and _not_ bitwise comparison. So, I think that it's pretty clear that the correct behavior is that the default behavior of opEquals for a struct like

struct S
{
    T t;
    U u;
}

mean that the compiler generates an opEquals like (ignoring the issues with the refness or constness of the argument or opEquals itself):

bool opEquals(S rhs)
{
    return t == rhs.t && u == rhs.u;
}

and that the types of T and U are completely irrelevant. If the compiler wants to optimize it to being a bitwise comparison when that would result in exactly the same behavior (save for performance differences), then great, but it should _never_ do bitwise comparison when that would result in different semantics from using == on each of the members.

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

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


Denis Shelomovskij <verylonglogin.reg@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |verylonglogin.reg@gmail.com


--- Comment #22 from Denis Shelomovskij <verylonglogin.reg@gmail.com> 2013-03-08 16:53:23 MSK ---
Just want to note the compiler often can't optimize a comparison to be bitwise because of align gaps which also should be ignored to conform `opEquals` behavior.

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

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



--- Comment #23 from github-bugzilla@puremagic.com 2013-03-09 03:13:46 PST ---
Commits pushed to master at https://github.com/D-Programming-Language/phobos

https://github.com/D-Programming-Language/phobos/commit/3eecfd2b1e6d7b57affbe175ac252149371623e3
fix Issue 3789 - Structs members that require non-bitwise comparison not
correctly compared

https://github.com/D-Programming-Language/phobos/commit/b4f5c4f6dd8ec65b68528a246e17c1c46c346e29 Merge pull request #1193 from 9rnsr/fix3789

Issue 3789 - Structs members that require non-bitwise comparison not correctly compared

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

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


Kenji Hara <k.hara.pg@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull
         Depends on|9671                        |


--- Comment #24 from Kenji Hara <k.hara.pg@gmail.com> 2013-03-09 07:37:10 PST ---
Partial fix for floating point, array, and union field comparison. https://github.com/D-Programming-Language/dmd/pull/1731

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

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



--- Comment #25 from bearophile_hugs@eml.cc 2013-04-23 01:07:30 PDT ---
(In reply to comment #24)
> Partial fix for floating point, array, and union field comparison. https://github.com/D-Programming-Language/dmd/pull/1731

Associative arrays too?
(The change log of the release should list exactly what parts of this bug are
fixed and what is not yet fixed.)

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

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


Walter Bright <bugzilla@digitalmars.com> changed:

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


--- Comment #26 from Walter Bright <bugzilla@digitalmars.com> 2013-04-23 10:47:33 PDT ---
(In reply to comment #22)
> Just want to note the compiler often can't optimize a comparison to be bitwise because of align gaps which also should be ignored to conform `opEquals` behavior.

The holes must be initialized to zero, by definition, so that a bitwise comparison can be done.

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

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



--- Comment #27 from Denis Shelomovskij <verylonglogin.reg@gmail.com> 2013-04-24 12:55:27 MSD ---
(In reply to comment #26)
> (In reply to comment #22)
> > Just want to note the compiler often can't optimize a comparison to be bitwise because of align gaps which also should be ignored to conform `opEquals` behavior.
> 
> The holes must be initialized to zero, by definition, so that a bitwise comparison can be done.

Nop. Holes are holes, that's all.

I'd be happy if it will be documented that padding holes must be zero-initialized. As for now we has the situation even worse than underdocumented (as always) C11, which partially defines it in "6.7.9 Initialization", para 10.

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

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


monarchdodra@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |monarchdodra@gmail.com


--- Comment #28 from monarchdodra@gmail.com 2013-04-24 13:26:39 PDT ---
(In reply to comment #27)
> (In reply to comment #26)
> > (In reply to comment #22)
> > > Just want to note the compiler often can't optimize a comparison to be bitwise because of align gaps which also should be ignored to conform `opEquals` behavior.
> > 
> > The holes must be initialized to zero, by definition, so that a bitwise comparison can be done.
> 
> Nop. Holes are holes, that's all.

Technically, D initializes all variables by first blitting T.init over them, which contains implementation defined values for the holes.

"Thanks" to this, the implementation may make optimizations that makes assumptions on the values in the gaps.

So even if you've initialized all the variables in a struct, if don't first blit the struct itself, your struct will be in a globally "not fully initialized" state. From there, an opEqual may fails, which would be legitimate undefined behavior.

So even if "holes are holes", D's intialization mechanics mean they have defined values.

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

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



--- Comment #29 from bearophile_hugs@eml.cc 2013-04-24 13:58:44 PDT ---
(In reply to comment #28)

> So even if you've initialized all the variables in a struct, if don't first blit the struct itself, your struct will be in a globally "not fully initialized" state. From there, an opEqual may fails, which would be legitimate undefined behavior.

All D programmers need to keep this in account. The usage of std.array.minimallyInitializedArray is one of such cases.

In D there is enough static introspection to statically tell if a struct has holes or not. So you can use this information to tell when it's safer to use uninitialized structs.

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