Fix test suite on big endian platforms

[maxcrees]

Fixes #897

[maxcrees]

I forgot endian.h isn't portable so I'll have to take another pass at this at some point.

[JG-Adams]

Question about this, why would checking endian at compile time address it?
If I compile for big-endian what happens if it run on little-endian?
So we're dealing with bitfield. C++ can't make it work on any system???
I though the issue only arise if you're doing things like reinterpret_cast?
I'm curious about this.

[OPNA2608]

https://github.com/mikepb/endian.h/blob/0f885cbba627efe9b8f763e1c2872e904fe0c0b1/endian.h has equivalents to endian.h for abunch of platforms, if you're still interested in completing this.

(I'd certainly love to see this get fixed here!)

[OPNA2608]

C++ can't make it work on any system???

Bitfields themselves work on any system.

Question about this, why would checking endian at compile time address it?
[...]
So we're dealing with bitfield. [...]
I though the issue only arise if you're doing things like reinterpret_cast? I'm curious about this.

...but they're being used within a union here. Location and order of bits within a bitfield in the underlying representation is irrelevant for its function, so it's implementation-defined. And accessing another datatype within a unions is essentially casting the representations between different types, thus also giving results with implementation-defined behaviour.

(The perfectly-correct way of implementing this, without relying on implementation-defined behaviour, would prolly be to drop the unions and implement access to the corresponding parts of the packed datatype via functions / helper macros that do bitwise ANDs and shifts to have an internally-consistent representation across architectures.)

If I compile for big-endian what happens if it run on little-endian?

If you lie to the compiler about your system's endianness, then you should expect the compiled program to misbehave. No surprise there. :)