Endianness in casting an array of two bytes into a single short

Question

Problem: I cannot understand the number 256 (2^8) in the extract of the IBM article:

On the other hand, if it's a big-endian system, the high byte is 1 and the value of x is 256.

Assume each element in an array consumes 4 bites, then the processor should read somehow: 1000 0000. If it is a big endian, it is 0001 0000 because endianness does not affect bits inside bytes. [2] Contradiction to the 256 in the article!?

Question: Why is the number 256_dec (=1000 0000_bin) and not 32_dec (=0001 0000_bin)?

[2] Endian issues do not affect sequences that have single bytes, because "byte" is considered an atomic unit from a storage point of view.

Answer 1

Because a byte is 8 bits, not 4. The 9th least significant bit in an unsigned int will have value 2^(9-1)=256. (the least significant has value 2^(1-1)=1).

From the IBM article:

unsigned char endian[2] = {1, 0};
short x;

x = *(short *) endian;

They're correct; the value is (short)256 on big-endian, or (short)1 on little-endian.

Writing out the bits, it's an array of {00000001_{base2}, 00000000_{base2}}. Big endian would interpret that bit array read left to right; little endian would swap the two bytes.

Answer 2

Answering your followup question: briefly, there is no "default size of an element in an array" in most programming languages.

In C (perhaps the most popular programming language), the size of an array element -- or anything, really -- depends on its type. For an array of char, the elements are usually 1 byte. But for other types, the size of each element is whatever the sizeof() operator gives. For example, many C implementations give sizeof(short) == 2, so if you make an array of short, it will then occupy 2*N bytes of memory, where N is the number of elements.

Many high-level languages discourage you from even attempting to discover how many bytes an element of an array requires. Giving a fixed number of bytes ties the designers' hands to always using that many bytes, which is good for transparency and code that relies on its binary representation, but bad for backward compatibility whenever some reason comes along to change the representation.

Hope that helps. (I didn't see the other comments until after I wrote the first version of this.)

Answer 3

256_dec is not 1000_0000_bin, it's 0000_0001_0000_0000_bin.

With swapped bytes (1 byte = 8 bits) this looks like 0000_0000_0000_0001_bin, which is 1_dec.