Consider the following on a 32-bit system:

    union Foo
    {
        struct
        {
            void* v;
            int i;
        }

        double d;
    }

    static assert(Foo.sizeof == 8);

    void copy(Foo* a, Foo* b)
    {
        version(one)
        {
            a.v = b.v;
            a.i = b.i;
        }
        version(two)
        {
            a.d = b.d;
        }
    }

Is there a difference between version one and version two? I was getting erroneous copies with version two on Linux and Windows, while it worked fine on OS X. Does it make a difference if the double is a NaN?

BTW, I know I can copy the structs directly using the assignment operator, but I was trying to avoid mixing (translating C -> D) with refactoring / improving.

On Tuesday, 22 October 2013 at 02:47:39 UTC, Luís Marques wrote:
>    static assert(Foo.sizeof == 8);

No idea how this is passing on your PC. Are you missing align directive in the snippet?

Ah, nvm, have not noticed the 32-bit part.

Given the lack of feedback, I'm sending a sample scenario and results:

    union Foo
    {
        struct
        {
            void* v;
            int i;
        }

        double d;
    }

    static assert(Foo.sizeof == 8);

    void copy(Foo* a, Foo* b)
    {
        version(one)
        {
            a.v = b.v;
            a.i = b.i;
        }
        version(two)
        {
            a.d = b.d;
        }
    }

    void main()
    {
        Foo a;
        Foo b;
        b.i = 0x7ff7a502;
        copy(&a, &b);
        writef("%x\n", a.i);
        writeln(a.d);
    }

Linux (32-bits):

    $ dmd -version=one test.d && ./test
    7ff7a502
    nan

    $ dmd -version=two test.d && ./test
    7fffa502  <-- different
    nan

OS X (64-bits, binary forced to 32-bits):

    $ dmd -m32 -version=one test.d && ./test
    7ff7a502
    nan

    $ dmd -m32 -version=two test.d && ./test
    7ff7a502   <-- equal
    nan

Can you check the value of `double` field in the copy origin (immediately after initialization). It may have something to do with floating arithmetic.

On Wednesday, 23 October 2013 at 14:43:07 UTC, Dicebot wrote:
> Can you check the value of `double` field in the copy origin (immediately after initialization). It may have something to do with floating arithmetic.

    // updated (b.v and writeln)
    void main()
    {
        Foo a;
        Foo b;
        b.v = null;
        b.i = 0x7ff7a502;
        writeln("b.d: ", b.d);
        copy(&a, &b);
        writef("a.i: %x\n", a.i);
        writeln("a.d: ", a.d);
    }

Linux:

    $ dmd -version=one test.d && ./test
    b.d: nan
    a.i: 7ff7a502
    a.d: nan

    $ dmd -version=two test.d && ./test
    b.d: nan
    a.i: 7fffa502
    a.d: nan

OS X:

    $ dmd -m32 -version=one test.d && ./test
    b.d: nan
    a.i: 7ff7a502
    a.d: nan

    $ dmd -m32 -version=two test.d && ./test
    b.d: nan
    a.i: 7ff7a502
    a.d: nan

I am afraid you will need to investigate IEEE spec on NaN assignment here to tell if this is a bug or valid behavior. I have made a quick check but it does not say anything about preserving NaN payload.

On Wednesday, 23 October 2013 at 15:21:20 UTC, Dicebot wrote:
> I am afraid you will need to investigate IEEE spec on NaN assignment here to tell if this is a bug or valid behavior. I have made a quick check but it does not say anything about preserving NaN payload.

OK, thanks for the attempt anyway :-)

On Wednesday, 23 October 2013 at 15:21:20 UTC, Dicebot wrote:
> I am afraid you will need to investigate IEEE spec on NaN assignment here to tell if this is a bug or valid behavior. I have made a quick check but it does not say anything about preserving NaN payload.

I checked, it is not the payload of the NaN that is being changed.