@tygre

Quote:

So "unions" are evil! (Joke intended!)

They are evil if inproperly used. They are blessing if used properly :) With help of union one can do very nice endian swap routines which get recognized by most compilers



such construct works always and it will be inlined without any penalty when the requested endian matches endian of target cpu. If this is not the case, proper cpu instruction will be emitted, such as rev on arm, or bswap on x86/x86_64, or movbe if the target x86 cpu supports it.

But, not only unions are "evil", consider bitfields as another candidate ;)

Quote:

Ouch! I see... In such a case, is the problem only coming from the compiler optimisation? As you wrote in other posts above, would recompiling with the proper "endian" parameter remove the problem entirely?

Yes, in that case selecting correct target cpu solves the problem.

Quote:

Besides unions that should be carefully checked and binary data... are there other "constructs" that could mess up endianness?

None coming to my mind right now. But, is binary data not bad enough? Keep in mind, binary data does not mean only file parsing. Binary data means filesystems and access to any hardware or peripherals, including graphics cards, network cards, audio and everything else. In such cases even simple increase of variable may turn into a nightmare if you "forget" about endianess.

Last edited by michalsc on 23-Apr-2021 at 06:47 AM.