That is, how easy is it to successfully recompile the source code in a different environment? The "different environment" can take several different forms. For example, we might move the source code to:

1. a different operating system

2. a different CPU

3. a different memory model

4. a different compiler

5. a different combination of the above

The permutations of the last item in the list are considerable. You might have the same operating system on different CPUs (e.g., UNIX on an 80486 or 68030), different operating systems on the same CPU (MS-DOS or XENIX on a 80386), different compilers on different CPUs and operating systems, and so on.

To say that C will always fulfill the portability needs for all of the possible system combinations that the programmer might face seems a bit much to assume. Indeed, it seems unlikely that any non-trivial program can be moved between computing environments without some modification. The real issue, then, is, "What can I do to make the port less difficult?"

It should be obvious that the more portable a program is, the less expensive it is to move the code to the new environment. The benefits accrue not only in getting the program up and running in the new environment, but also in the support of the program once the port is complete.

The degree to which your program is (or will be) portable is influenced by where you are in the development cycle. Writing portable code while the program is in the design stage is one matter; modifying existing code to be portable is quite another. In the remainder of this article, we will examine some of the things we did in both situations to improve program portability.

You should also exercise care in making assumptions about other resources and features available to you in the two environments. For example, if the existing code was written with a K&R compiler and the target machine supports an ANSI compiler, certain resources and features may be missing. The K&R compiler will support low-level (unbuffered) file I/O while the ANSI compiler is only required to supply high-level (buffered) functions as part of the standard library. Although present compilers support both types of file I/O, it might prove costly to make the assumption in the future.

#define TABLESIZE 50

for (i = 0; i < TABLESIZE; i++) {
   printf("\n%d", number[i]);
}

While this approach reduces the amount of editing required in the source file, a better solution is possible. For example:

int tablesize;
/*  main() plus some other code */
tablesize = sizeof(number) / sizeof(number[0]);
for (i = 0; i < tablesize; i++) {
   printf("\n%d", number[i]);
}

Another portability problem arises with macros used as bit masks. While the macro

#define INTEGER_MASK 0x7fff

#define INTERGER_POINTER int  *
/* ....some code */
INTEGER_POINTER table;

int *table;

INTEGER_POINTER table, delta;

int *table, delta;

typedef int *INTEGER_POINTER;

We should have written all of the string constants to be defined as an array of pointers to char. For example:

char *message[] = {
   "Select variable name:",     /*  Message # 0 */
   "All or Subset (A, S):",     /*  1 */
   "Printer or File (P, F):"    /*  2 */
   /* More in the list */
   "Out of memory"              /*  N */
};

As you may know, many foreign countries use different formats for dates, time, currency, and similar information. Although our packages don't have these particular formatting requirements, they may well apply to your application. If that is the case, you should examine the locale.h header file to see if any of the symbolic constants defined there can be used to advantage in your code. It may help make the port a bit easier.

While we're on the subject, it's been our experience that scanf() is not a good function to use for data input. Not only is scanf() a huge function and difficult to use properly, the function makes it difficult for your program to sense input errors. Further, functions that rely on a terminating newline character don't translate well in some environments. In Windows, for example, pressing the Enter key is the same as clicking on the OK button.

Another problem is that the behavior of scanf() may vary among compilers. For example, ANSI states that the e and g conversion characters are not case sensitive, while System V doesn't specify how these conversion characters are viewed. On the other hand, ANSI specifies that the l (for "long") modifier in scanf() is case sensitive. For example, "%lf" differs from "%Lf". The latter form is used to get a long double. In some environments, however, a long double won't even be available in scanf() because that data type is not supported (e.g., System V). Little details like these need to be investigated if you still wish to use scanf().

A related problem arises when testing for the end of a user's input from the keyboard, regardless of the function used to capture the input. Some compilers use the newline character ('\n') to terminate input while others use the carriage return character ('\r'). For example, the statement

if (buff[0] == '\n') {
   /* The user didn't enter anything */
}

#define ENDOFINPUT '\r'
if (buff[0] == ENDOFINPUT) {
   /* The user didn't
      enter anything */
}

#define RECORD 50
fread(buf, RECORD, 1, fpin);

If you are moving to an ANSI compliant compiler, the limits.h header file should be helpful in answering such questions. If your present compiler does not have the limits.h header file, you might want to consider writing your own. Most compilers supply enough information about the data types that creating your own limits.h header file is not very difficult. (If you haven't done so already, you should examine the symbolic constants defined in this header file.)

Another header file that may prove useful is float.h. It defines almost everything you need to know about floating point variables (e.g., number of digits of precision, floating point exceptions, exponent limits, etc.). One potential problem area for programs that use floating point variables is the epsilon factor for a floating point number. (This factor is called DBL_EPSILON for type double.) The epsilon factor is the smallest value that can be added to 1.0 and satisfy the condition:

1.0 + DBL_EPSILON != 1.0

Some compilers do not allow nested comments. It is a real pain to "uncomment" nested comments. We have since moved away from commenting out test code and now use preprocessor directives to conditionally include the test code in the program. For example, we used to comment out the code in the following manner:

/*
/*  Inspect the values for
   table[] */
for (i = 0; i < MAXSIZE; i++) {
   printf("table[%d] = %g", i, table[i]);
}
*/

#ifdef DEBUG
/* Inspect the values for
   table[] */
for (i = 0; i < MAXSIZE; i++) {
   printf("table[%d] = %g", i, table[i]);
}
#endif

Finally, I'd like to present a brief laundry list of don'ts that can cause problems in the middle of a code port.

Don't use lowercase l as a modifier to a long constant; it looks too much like the digit 1. Use the uppercase L, as in

a = 20L;

Don't assume a pointer is a fixed length, especially in a mixed-model environment. Sometimes all data pointers are only two bytes, but function pointers are four bytes.

Don't assume wildcard characters are universal across environments. A question mark and asterisk may mean nothing on a different system.

Don't assume a filename is limited to a certain length.

Don't assume a NULL pointer means all bits are set to 0; it is implementation defined. All you can safely assume is that the test for a NULL pointer behaves in the normal way (even though the bits may be nonzero).

Don't use environment variables if you can avoid them. If you can't live without them, make sure you mark those functions that use them.

Don't create your own symbolic constants if ANSI already provides for them (e.g., DBL_EPSILON, SEEK_CUR, etc.).

As a final rule, if you follow most of the suggestions presented here, do take the estimated time required for the port, double it, and try to live within that time frame. C is not the perfect portable language, but it's way out in front of whatever is in second place.