Little endian Vs Big endian

Question

Lets say I have 4Byte integer and I want to cast it to 2Byte short integer. Am I right that in both (little and big endian) short integer will consist of 2 least significant bytes of this 4Byte integer?

Second question:
What will be the result of such code in little endian and big endian processor?

int i = some_number;  
short s = *(short*)&i;

IMHO in big endian processor 2 most significant bytes would be copied, and in little endian 2 least significant bytes would be copied.

Answer 1

Am I right that in both short integer will consist of 2 least significant bytes of this 4Byte integer?

Yes, by definition.

The difference between bigE and littleE is whether the least significant byte is at the lowest address or not. On a little endian processor, the lowest addresses are the least significant bits, x86 does it this way.

These give the same result on little E.

short s = (short)i;
short s = *(short*)&i;

On a big endian processor, the highest addresses are the least significant bits, 68000 and Power PC do it this way (actually Power PC can be both, but PPC machines from Apple use bigE)

These give the same result on big E.

short s = (short)i;
short s = ((short*)&i)[1]; // (assuming i is 4 byte int)

So, as you can see, little endian allows you to get at the least significant bits of an operand without knowning how big it is. little E has advantages for preserving backward compatibility.

So what's the advantage of big endian? It creates hex dumps that are easier to read.

Really, the engineers at Motorola thought that easing the burden of reading hex dumps was more important than backward compatibility. The engineers at Intel believed the opposite.

Answer 2

1. Yes. When you convert values, you don't have to worry about endianness.

2. Yes. When you convert pointers, you do.