Common Causes of Portability Problems

This section describes some of the common causes of portability problems.

Non-Standard Language Extensions

U sing industry standards is crucial to ensuring that your code is portable.

Code that uses only standard features is more easily ported to other systems that support the same standard. The section "Industry Standards" at the end of this chapter summarizes various industry standards that HP is committed to following.

The HP- UX compilers have compile line options (command options) that make the compilers flag the use of non-portable constructs in your programs.

Table 2-1 summarizes these options for each language. For details on these options, see the appropriate page in the HP-UX Reference.

2-2 Writing Portable Programs

Table 2·1. Standard·Enforcing Compile Line Options

Language Option Description

C -As The parameter s can be the letter c or a. If it is c ( - Ac), the compiler enforces the C language as defined by Kernighan and Ritchie's The C Programming Language, First Edition, sometimes referred to as K&R C. It also includes some Berkeley Software Distribution (BSD) extensions.

If it is a (-Aa), the compiler enforces the ANSI cause the compiler to generate warning messages.

(See /77(1).)

Pascal -A Produces error messages for any non-ANSI Pascal features. (See pc(1).)

Unstructured Programming

Structured programs are easier to understand. A well designed program that is modular is inherently more portable.

To this end, HP- UX provides tools that can aid in finding unstructured program constructs~for example, uninitialized variables or unreachable code. For the C programming language, the lint program can be used; for FORTRAN, the lintfor program is useful. Since these programs often produce large quantities of warning messages to stderr, it is best to capture their output by redirecting it to a file for later viewing.

Note also that these commands do not produce an object file~they only check program structure.

Writing Portable Programs 2·3

2

2

Compile Line Options and Compiler Directives

Conlpile line options that flag the use of non-standard features, such as those shown in Table 2-1, are clearly useful to programmers who want to write portable code. However, some options and directives enable systenl-dependent features and extensions that decrease the portability of code. Be sure to review the use of options and directives when porting code between systems because it is unlikely that the systems you port to will support all the same directives.

Assembly Language Code

Because assembly language code is based on the architecture of the machine on which it runs, assembly language code is not usually highly portable between systems. When the assembly language routines are ported to a system that has a different architecture, the assembly language will almost certainly need rewriting. And assembly language is one of the most difficult languages to work in for most programmers. Fortunately, with the optinlization technologies available on many compilers today, programming in assembly language is less of a necessity than it used to be.

Absolute Addressing

Absolute addressing is the programming practice of using numeric constants to refer to objects by their absolute virtual or physical memory addresses as opposed to referring to symbolic addresses. Absolute addressing is

sometimes done to take advantage of knowledge about the location of various objects in virtual memory. The problem is that such knowledge is highly system-dependent, and, therefore, tends not to be portable. Note that absolute addressing is not the same as incrementing or decrementing pointers.

Language Semantics

Because a programming language defines a program's meaning, differences in semantics for a given language between different systems can affect portability.

Unless such semantics are completely identical, you may find that a program written in that language will produce different results on the two systems.

Unfortunately, it is often difficult to know beforehand whether the semantics of a compiler implementation for one language will be the same on another system. To help you to be aware of potential differences, later chapters on 2·4 Writing Portable Programs

porting C, FO RTRAN, and Pascal sumlnarize some of the languages' features that nlay have different semantics on other systems.

Floating-Point Fuzziness

Floating-point operations can complicate compatibility. Computer floating-point values only closely approximate actual numbers, so when comparing floating-point values, it is best to compare to a range of values instead of a single value. This technique is known as a "fuzzy compare." For example, in a fragment of Pascal code, you could replace

if (x

=

with a more accommodating fragment of code such as:

if (abs(x - 1.2267) < err_margin) then y:= y + 1;

for comparisons. The value of err _margin will be very small; however, it will not be constant across all HP- UX implementations. For example, it will differ among Series 300/400 systems, depending on whether the program was compiled with the +ffpa or -0 option.

For more information about how floating-point operations can affect compatibility, refer to the HP-UX Floating-Point Guide.

Data File Incompatibility and Input/Output

File manipulation and input/output operations have traditionally been two of the most troublesome areas impacting portability. Most language standards are intentionally vague in these areas to allow vendors to make the most effective use of their architectures. Unfortunately, file manipulation and input/output operations are also frequently critical to performance, so they are usually manipulated in a system-dependent manner. The apparently conflicting goals of portability and performance can be met by a careful design that encapsulates interface routines.

Additionally, input/output operations should be performed in the same language as the main program; for example, avoid having a main FORTRAN program that calls C input/output routines. Methods exist to do input/output

Writing Portable Programs 2-5

2

2

from external routines, but they are not generic. In addition, difficult problems can be encountered if input/output is performed from more than one language at a time since each language has its own buffers.

Data Alignment Differences

Data alignment refers to the way in which a system or language aligns data structures in virtual memory. For example, by default Series 300/400 C aligns variables of type double on 4-byte boundaries, while Series 700/800 C aligns them on 8-byte boundaries. This is done to realize greater efficiency in accessing data based on a particular hardware architecture.

These differences in alignment can cause problems for code that makes assumptions about the location of variables. It can also cause problems for programs that write and read data structures to files: A file written by one system may be read incorrectly by the same code on another system because the variable alignment is different on the two systems.

Data type alignments for each language are summarized in the appropriate language chapters later in this manual. In addition, HP- UX provides ways to force a particular alignment on different systems; for example, to force Series 700/800 C to align data the same way as Series 300/400, use the

#pragma HP _ALIGN HPUX_WORD directive. These directives are covered in later language- specific chapters.