Specifications

Red Hat Enterprise Linux to Oracle Solaris Porting Guide
20
type—and even the size of the type itself—can differ. And this is exactly what happens if the data
corresponding to
mystruct is moved between an x86/x64 system and a SPARC system, even though
the types used in the
struct are of the same size.
Byte Ordering
Different microprocessor vendors use different byte-ordering schemes. For example, Intel processors
have traditionally been little-endian. Motorola processors have always been big-endian. Big-endian is an
order in which the "big end" (the most-significant byte) is stored first. Little-endian is an order in
which the "little end" (the least-significant byte) is stored first.
Figure 3-4 and Figure 3-5 show a representation of the hexadecimal number 0xFF342109 on a
big-endian and little-endian machine. The contents of memory locations 0x1000 to 0x1003 are shown.
0x1000 0x1001 0x1002 0x1003
Figure 3-4. Representation of 0xFF342109 on a little-endian system such as with Linux on an x86 system.
0x1000 0x1001 0x1002 0x1003
Figure 3-5. Representation of 0xFF342109 on a big-endian system such as with Oracle Solaris on a SPARC system.
Data Conversion for Interoperability
The logic for converting between the big-endian and little-endian formats is actually quite straight
forward. Looking at the diagrams above, it is obvious that just by swapping the appropriate bytes, one
format can be converted to the other.
To account for communication over a network that has machines with diverse architectures, generally
the data is converted in “network byte order” at the transmitting end before being sent to the network,
and the received data is converted back to “host byte order” after the receipt of the packet at the
destination host. Ready-made library conversion routines are shipped with the operating system to help
with this conversion, for example:
ntohl( ) // Network-to-host byte order
htonl() // Host–to-network byte order