The infamous "Endian issue" occurs because the Power PC and Intel processors arrange the byte order of their data differently in memory. The Power PC processor is "Big Endian" in that it stores a data value's MSB in the lowest byte address, while the Intel is "Little Endian" because it places the value's LSB in the lowest byte address. There is no technical advantage to either byte-ordering scheme. When you access data by its natural size (say using a 16-bit access for a 16-bit variable), how the bytes are arranged doesn't matter and programs operate as they should. However, when you access multibyte variables through overlapping unions, or access data structures with hard-coded offsets, then the position of bytes within the variable do matter. Although the program's code executes flawlessly, the retrieved data is garbled because of where the processor stores the bytes in memory. Stated another way, code written for a Big-Endian processor accesses the wrong memory locations on a Little-Endian processor. Consequently, the wrong values are fetched, which produces disastrous results.
The Endian issue manifests itself another way when multibyte data is accessed piecewise as bytes and then reassembled into larger data variables or structures. This often occurs when an application reads data from a file or through a network. The bad news is that any application that performs disk I/O on binary data (such as reading a 16-bit audio stream), or uses network communications (such as e-mail or a web browser), can be plagued by this problem. The good news is that each set of Mac OS X APIs provide built-in methods that can reorganize the bytes (this rearrangement is termed "byte swapping") for you. For more information on these routines, see the Apple Core Endian Reference document (http:// developer.apple.com/documentation/ Carbon/Reference/CoreEndianReference/ index.html).
—T.T.
Back to Article