Portability between CPUs

Even GNU systems will differ because of differences among CPU types--for example, difference in byte ordering and alignment requirements. It is absolutely essential to handle these differences. However, don't make any effort to cater to the possibility that an int will be less than 32 bits. We don't support 16-bit machines in GNU.

Don't assume that the address of an int object is also the address of its least-significant byte. This is false on big-endian machines. Thus, don't make the following mistake:

int c;
...
while ((c = getchar()) != EOF)
  write(file_descriptor, &c, 1);

When calling functions, you need not worry about the difference between pointers of various types, or between pointers and integers. On most machines, there's no difference anyway. As for the few machines where there is a difference, all of them support ANSI C, so you can use prototypes (conditionalized to be active only in ANSI C) to make the code work on those systems.

In certain cases, it is ok to pass integer and pointer arguments indiscriminately to the same function, and use no prototype on any system. For example, many GNU programs have error-reporting functions that pass their arguments along to printf and friends:

error (s, a1, a2, a3)
     char *s;
     int a1, a2, a3;
{
  fprintf (stderr, "error: ");
  fprintf (stderr, s, a1, a2, a3);
}

In practice, this works on all machines, and it is much simpler than any "correct" alternative. Be sure not to use a prototype for such functions.

However, avoid casting pointers to integers unless you really need to. These assumptions really reduce portability, and in most programs they are easy to avoid. In the cases where casting pointers to integers is essential--such as, a Lisp interpreter which stores type information as well as an address in one word--it is ok to do so, but you'll have to make explicit provisions to handle different word sizes.

Go to the first, previous, next, last section, table of contents.