Use abstraction and encapsulation to restrict and control unavoidable non-portable code. By staying within the intersection of constraints and by localizing system dependencies, your code will become cleaner and more general as it is ported.
8.1 Language
Stick to the standard.
The first step to portable code is of course to program in a high-level language, and within the language standard if there is one. Binaries don't port well, but source code does.
Program in the mainstream.
Use only those features for which the language definition is unambiguous and well understood. Such features are more likely to be widely available and to behave the same way everywhere. We call this the mainstream of the language.
Beware of language trouble spots.
As we mentioned, standards leave some things intentionally undefined or unspecified, usually to give compiler writers more flexibility. The list of such behaviors is discouragingly long.
Sizes of data types.
Order of evaluation.
In C and C++, the order of evaluation of operands of expressions, side effects, and function arguments is not defined.
Signedness of char.
Arithmetic or logical shift.
Right shifts of signed quantities with the >> operator may be arithmetic (a copy of the sign bit is propagated during the shift) or logical (zeros fill the vacated bits during the shift). Again, learning from the problems with C and C++, Java reserves >> for arithmetic right shift and provides a separate operator >>> for logical right shift.
Byte order.
Alignment of structure and class members.
The alignment of items within structures, classes, and unions is not defined. except that members are laid out in the order of declaration. For example, in this structure,
struct X {
char c;
int i;
};
the address of i could be 2,4, or 8 bytes from the beginning of the structure. A few machines allow ints to be stored on odd boundaries, but most demand that an n-byte primitive data type be stored at an n-byte boundary, for example that doubles, which are usually 8 bytes long, are stored at addresses that are multiples of 8. On top of this, the compiler writer may make further adjustments, such as forcing alignment for performance reasons. You should never assume that the elements of a structure occupy contiguous memory.
Alignment restrictions introduce "holes"; struct X will have at least one byte of unused space. These holes imply that a structure may be bigger than the sum of its member sizes, and will vary from machine to machine. If you're allocating memory to hold one, you must ask for sizeof (struct X) bytes, not sizeof (char) +sizeof(int).
Bitfields.
Bitfields are so machine-dependent that no one should use them.Don't compare a char to EOF. Always use sizeof to compute the size of types and objects. Never right shift a signed value. Make sure the data type is big enough for the range of values you are storing in it.
Try several compilers.
Different compilers sometimes see your program differently, so you should take advantage of their help. Turn on all compiler warnings. Try multiple compilers on the same machine and on different machines.
8.2 Headers and libraries
8.3 Program Organization
There are two major approaches to portability, which we will call union and intersection. The union approach is to use the best features of each particular system, and make the compilation and installation process conditional on properties of the local environment. The resulting code handles the union of all scenarios, taking advantage of the strengths of each system. The drawbacks include the size and complexity of the installation process and the complexity of code riddled with compile-time conditionals.
Use only features available everywhere
Avoid conditional compilation.
Some large systems are distributed with a configuration script to tailor code to the local environment. At compilation time, the script tests the environment properties-location of header files and libraries, byte order within words, size of types, implementations known to be broken (surprisingly common), and so on-and generates configuration parameters or makefiles that will give the right configuration settings for that situation, These scripts can be large and intricate, a significant fraction of a software distribution, and require continual maintenance to keep them working. Sometimes such techniques are necessary but the more portable and #i fdef-free the code is, the simpler and more reliable the configuration and installation will be.
8.4 Isolation
Localize system dependencies in separate files.
Hide system dependencies behind interfaces.
8.5 Data Exchange
Textual data moves readily from one system to another and is the simplest portable way to exchange arbitrary information between systems.
Use text for data exchange.
Text is easy to manipulate with other tools and to process in unexpected ways.
8.6 Byte Order
Despite the disadvantages discussed above, binary data is sometimes necessary. It can be significantly more compact and faster to decode, factors that make it essential for many problems in computer networking. But binary data has severe portability problems. At least one issue is decided: all modem machines have 8-bit bytes. Different machines have different representations of any object larger than a byte, however, so relying on specific properties is a mistake. A short integer (typically 16 bits, or two bytes) may have its low-order byte stored at a lower address than the high-order byte (little-endian). or at a higher address (big-endian). The choice is arbitrary, and some machines even support both modes.
Use a fixed byte order for data exchange.
Write the bytes in a canonical order using portable code.
