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:
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 :)
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:
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.
2) What are other "typical" C code that is not "endianness-safe"?
It is no important how often thing like that are used. It is important they exist. Which results in additional work on ARM, like code analysis, tests. Where on ppc it is just recompilation.