Open System Services Porting Guide (G06.29+, H06.06+, J06.03+)

using the proper set of tools, you can identify the areas that need the most attention in performing
the port:
• The lint program, found on most UNIX systems, finds bad constructs in C programs. It
identifies variables used before they are set, unreachable program segments, and functions
that return unused values.
• A findcalls tool performs a simple lexical analysis of C source code by searching for the
use of function calls. By comparing function calls, findcalls identifies the function calls not
supported by the target environment and that therefore need replacing by equivalent function
calls.
• A third-party tool, CodeCheck, checks program source code for compliance with ISO/ANSI C,
POSIX.1, and POSIX.2 standards. Another third-party tool, Open Systems Portability Checker
(OSPC), does a thorough source code check for ISO/ANSI C compliance and a number of
POSIX standards by using profile specifications.
These tools are further described in Chapter 3 (page 48).
Design Trade-Offs
All of the standard functions in the OSS environment behave according to open specifications, but
because the OSS environment is based on the NonStop operating system, the performance of
some of these functions might be different than in other UNIX environments. For example, the cost
(time and resources) to create a process is higher in the OSS environment than in most UNIX
environments. This factor can result in different performance among programs that create many
processes
To improve performance, redesign your program to use persistent processes for each major function
rather than create a new process to perform the function. The design trade-offs associated with
process-creation and other major functions are discussed in Chapter 6 (page 85).
Equivalent Features
Some features found in UNIX environments are not provided in the OSS programming environment,
are implemented differently, or are provided with slightly different functions. These features include:
• Memory mapping and memory mapped files
• Memory allocation
• Multithreading
• Semaphores
• STREAMS
• TLI/XTI
If your program uses these features, some changes might be required in the source code to use
the equivalent features provided in the OSS environment. See Chapter 6 (page 85), for a discussion
on each of these features.
Standard Functions
To maximize portability, standard functions should be used wherever possible. If your application
program is limited to using standard functions defined in the ISO/ANSI C, POSIX.1 and POSIX.2
standards, and the XPG4 system interface specifications, it should have a wide scope of portability.
See “Porting Is Easier When Standards Are Used” (page 24).
Equivalent Functions
If the program being ported to the OSS environment uses nonstandard functions, these should be
modified to use the equivalent standard functions. If an equivalent standard function is unavailable,
the function might need to be rewritten in standard ISO/ANSI C, or the logic of the program might
General Porting Guidelines 109