The Psychology of Quality and More

C Style: Standards and Guidelines (contents)

CHAPTER 10 : Programming Usage

PART 4 : USAGE

CHAPTER 10 : Programming Usage
10.1 Elegant programming
10.2 Performance programming
10.3 Defensive programming
10.4 Error handling
10.5 Diagnostics
10.6 Integrity and Recovery
10.7 Testability
10.8 Portability
10.9 Localization
10.10 Usability
10.11 Summary

<--Prev page | Next page -->

10.8  Portability

There are two main areas that must be taken into account when considering the portability of code: interfaces and compilers. The degree to which you will want to consider portability will largely depend on the targeting and lifetime of your code, although there are many programs which have been ported to many environments, yet which started life as simple, short-term solutions. The more useful the program, the more likely it is that it will one day need to be ported.

10.8.1  Interface portability

Problems affecting portability are commonly hardware-related, although a 'standard' library or subsystem function may vary in the way that it is called, the actions it performs or the values that it returns (this could happen, for example, when an operating system is upgraded). The common factor is that the interface to the system changes.

The easiest way of simplifying porting between machines which have different interfaces, to hardware or to other software, is to isolate all portions of the code that define and access these interfaces.

10.8.2  Compiler portability

The definition of the C language includes elements that are specifically undefined, such as the length of a variable name or the order of evaluation of an expression. The language itself has evolved from the original K&R to the ANSI C definition.

For maximum portability, undefined items should be generally avoided, and only the basic K&R definition should be used, although macros may be used to implement some pseudo-ANSI or alternative items:

#ifdef __STDC__              /* ANSI compiler */
    typedef void    *VOIDPTR;
#else                        /* non-ANSI      */
#   define volatile
#   define const
#   define void     int
    typedef char    *VOIDPTR;
#endif

-------------------------------------------------

In fact, many pre-ANSI compilers implement features that ANSI adopted. If forward compatibility only is needed, then advantage may be taken of the available ANSI features, such as function prototyping.

Even with K&R or ANSI C, there are items, such as the length of integers or the operation of logical shifts which are not guaranteed to be consistent between systems. Any items described as 'implementation defined' should either be treated with care (typically isolated with other non-portable items) or not used at all.

<--Prev page | Next page -->