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

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

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

Answer 2

First of all, you may already know it but let me mention that the size of int is not guaranteed to be 4 bytes and that of short, 2 bytes across all platforms.

If in your first question you mean something like this:

int i = ...;
short s = (short)i;

then yes, s will contain the lower byte(s) of i.

I think the answer to your second question is also yes; at the byte level the endianness of the system does come into play.

Answer 3

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 4

You should be aware that your second example

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

is not valid C code as it violates strict aliasing rules. It is likely to fail under some optimization levels and/or compilers.

Use unions for that:

union {
   int   i;
   short s;
} my_union;

my_union.i = some_number;
printf("%d\n",my_union.s);

Also, as others noted, you can't assume that your ints will be 4 bytes. Better use int32_t and int16_t when you need specific sizes.

Answer 5

If you really want to convert an int to a short, then just do that:

short int_to_short(int n) {
  if (n < SHRT_MIN) return SHRT_MIN;
  if (n > SHRT_MAX) return SHRT_MAX;
  return (short)n;
}

You don't have to even worry about endian, the language handles that for you. If you are sure n is within the range of a short, then you can skip the check, too.