Challenge

Modify code that includes hex constants used as byte arrays written for big-endian systems to run properly on Intel® architecture. Endianness refers to how a data element and its individual bytes are stored (or addressed in memory). The SPARC* architecture is big-endian, which indicates that it has forward-byte ordering: the lowest address (or leftmost) in a multi-byte value is the most significant byte. IA-32 architectures are little-endian, with the lowest address (or rightmost) in a multi-byte value being the least significant byte. If the target application is currently running under Solaris on a SPARC platform and the goal is to port to Linux on an Intel architecture, byte ordering may become an issue.

An endian problem occurs when a 32-bit value is sometimes treated as a 32-bit value (an integer) and sometimes as an array of 4 characters.

Using byte arrays with hex constants implies an order for the bytes stored in the array with byte 0 at array index 0, byte 1 at array index 1, and so forth. With regard to the most and least significant bytes, the location is determined by the endian order of the architecture, rather than how the values are stored in the array.

For example, the following array is equivalent to the number 0x11223344 on big-endian machines and the number 0x44332211 on little-endian machines:

char a[4] = {0x11, 0x22, 0x33, 0x44}; 

Solution

Avoid using hex constants stored in byte arrays. If this practice cannot be avoided, then take special care to address into the array according to the endian model implemented by the architecture.

Sources

Solaris to Linux Porting Guide

Porting Solaris Applications to Linux: Endian Issues