This:

typedef union {
    struct {
        unsigned sign     : 1;
        unsigned exponent :11;
        U64      mantissa :52;
    };
    double d;
    U64 u;
} DFields;
[download]

Should be this:

typedef union {
    struct {
        U64 sign     : 1;
        U64 exponent :11;
        U64 mantissa :52;
    };
    double d;
    U64 u;
} DFields;
[download]

Turns out that unless all the bit fields are defined to be of the same unsigned type, they will not be mapped to the same unit of memory.

I originally had them all defined as just unsigned; but the compiler complained that the mantissa was too large for a 32-bit uint. So, I switch it to U64 and it compiled.

The problem is that produces a struct that occupies more than 64-bits. The first two bitfields are merged into a U32, but because the third is a different underlying type, it gets mapped to a different chunk of uninitialised memory. Hence, the apparently random nature of the output.

Making all three fields the same type means they get amalgamated into a single 64-bit piece of ram. (But it took some searching to locate this rather arcane piece of knowledge.)

Hmm, interesting. I also would have thought that in a union-type, all variables start at offset zero.

I thought i have seen it used something like this (pseudo-code, my C coding days are mostly over so i'm not really sure how this is all supposed to look): Image you want to have different IP records in memory, say,

typedef struct {
    uint32 type;
    char ip[4];
} ipv4;

typedef struct {
    uint32 type;
    char ip[16];
} ipv6;
[download]

Then you would be able to have an union type of both and access the first field ("type") to cast the variable to the the correct typedef?

As said, my C coding days are mostly over. But since i have some XS work coming up, i might as well start to think about such problems right now :-)

"For me, programming in Perl is like my cooking. The result may not always taste nice, but it's quick, painless and it get's food on the table."