@michalsc

Quote:

More then you think. The most common case is working with binary data of any form. Imagine some simple check of a header of some binary file: if (data8[0] == 'E' && data8[1] == 'L' && data8[2] == 'F')

I don't understand. This code is endianess safe no matter if compiler optimizes it into 32 bit check or not.

@michalsc

Thank you so much! This is the first and best explanation I never had about endianness and the problems that it brings! I can only repeat: More!

(I don't want to despair Number6... but let's be honest: this discussion about endianness is much more interesting than the endless one about the lawsuit(s). I truly appreciate Number6's posts and contributions; it's the never-ending follow-up "discussions" about who's right and who's wrong that I find tedious.)

Quote:

Quote: 1) How often would C code do something like that More often then I would like to. Last example is the Capstone project which I use to disassemble aarch64 and m68k instructions in my Emu68 project. Capstone is written with endianess in mind, but still it failed for me. Since I am using AArch64 in big endian mode, capstone was showing float numbers incorrectly. Surprisingly enough, all integers and double numbers were displayed properly. Why? After checking the source code I have noticed that the immediate operands of instructions are stored in a union like this one: typedef union { uint64_t i_num; double d_num; float f_num; } immediate; When analysing the opcodes, capstone was promoting all integer immediates to 64bit form and stored in i_num field. For floating point numbers it was reading the number as integer (either uint32_t or uint64_t) and storing into i_num directly without any further processing of the number. On little endian CPUs all went just ok. Fetching any value was correct, because the data begins from the lowest address for every type. In big endian mode on AArch64 it failed, because the 32bit float number was in wrong half of the 64-bit wide field. So you see, even if you try to be endian aware, issues can just pop out in unexpected moments :)

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

Quote:

Quote: 2) What are other "typical" C code that is not "endianness-safe"? More then you think. The most common case is working with binary data of any form. Imagine some simple check of a header of some binary file: if (data8[0] == 'E' && data8[1] == 'L' && data8[2] == 'F') Compiler may optimize it to a 32bit number check (with ignoring data[3] through a mask) instead of testing one byte after another. For big endian machine such optimization could look like this: if ((data32[0] & 0xffffff00) == 'ELF\0') where on little endian machine it would be rather something like if ((data32[0] & 0x00ffffff) == '\0FLE') Thereby you have no control over it what the compiler will "optimize" for you and what not. Alone for this reason coexistence of big- and little-endian binaries and programms in a fully open OS environment as it is in case of AmigaOS and derivates is not possible. It does not work since after compilation the information about structure of the data is lost.

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?

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

I'm really curious

_________________
Tygre
Scientific Progress Goes Boing!

@thread that used to be about trademarks

A500 under examination

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*