1

Introduction to HP C and C++ for

NonStop Systems
• TNS C Language System on page 1-1
• TNS C++ Language System on page 1-3
• TNS/R Native C and C++ Language System on page 1-4
• Features of TNS/R Native C and C++ on page 1-9
• Writing Portable Programs on page 1-11
• Porting Programs to HP C and C++ for NonStop Systems on page 1-15
• Guardian and OSS Environment Interoperability on page 1-16

TNS C Language System

The HP TNS C language system for NonStop servers generates TNS C programs for
the Guardian and OSS environments. The C preprocessor, C compiler, C run-time
library, and Binder comprise the TNS C language system. Optional components of this
system include the Accelerator, the Inspect symbolic debugger, and the NonStop
SQL/MP compiler.
HP C for NonStop systems conforms to the C language standard as set forth in
ISO/IEC 9899:1990, Programming Languages–C. (This is technically identical to ANSI
C X3.159-1989, Programming Language C.) HP C includes several extensions to
ISO/ANSI Standard C that makes C an effective language for writing applications that
run on NonStop systems. For details, see Section 2, C and C++ Extensions.

C Preprocessor
The C preprocessor, Cprep, manipulates the text of a source file as the first phase of
compilation. You can run Cprep as an independent process in either the Guardian or
OSS environment. The C preprocessor is embedded in the C compiler that runs in the
Guardian environment. The C compiler that runs in the OSS environment does not
contain the C preprocessor; Cprep must be run separately. (The OSS TNS c89 utility
runs the C preprocessor by default.)

C Compiler
The C compiler then translates C source text into machine language code. If there are
mistakes in your program, then error messages are generated; if not, object code is
generated.

HP C/C++ Programmer’s Guide for NonStop Systems —429301-004

1 -1
Introduction to HP C and C++ for NonStop Systems C Run-Time Library

C Run-Time Library
The C run-time library contains the functions defined in the ISO/ANSI C standard as
well as several functions that are extensions to the standard. Macros that are not in the
library are expanded during the preprocessing phase of the compiler.
The Guardian C run-time library and the OSS C run-time library share the same set of
header files. Header files contain function prototypes and the variable and type
declarations used by the functions.
For the complete semantics and syntax of the C run-time library in the Guardian TNS C
environment, see the Guardian TNS C Library Calls Reference Manual. For the
complete semantics and syntax of the C run-time library in the OSS environment, see
the Open System Services Library Calls Reference Manual.

Binder
The Binder collects and links object files generated by the C compiler and produces an
executable object file (a program file).

Accelerator
The Accelerator enables you to increase the performance of programs that run on
TNS/R systems. The Accelerator optimizes TNS program files (compiled and bound
object files) to take advantage of the TNS/R architecture.

Inspect Symbolic Debugger

The Inspect symbolic debugger is an interactive tool that enables you to identify and
correct programming errors in programs.You can use the Inspect debugger to:
• Step through code
• Set breakpoints
• Display source
• Display variables
For details on debugging capabilities, refer to the Inspect Manual and the Debug
Manual.

NonStop SQL/MP Compiler

The NonStop SQL/MP compiler processes embedded SQL statements from C source
programs and generates the correct NonStop SQL/MP database calls.

HP C/C++ Programmer’s Guide for NonStop Systems —429301-004

1 -2
Introduction to HP C and C++ for NonStop Systems TNS C++ Language System

TNS C++ Language System

The TNS C++ language system includes the TNS C language system and the HP C++
translator, Cfront. Cfront supports the C++ language features provided in the UNIX
System Labs (USL) C++ translator, Cfront, version 3.0. These features are described
in The Annotated C++ Reference Manual (ANSI Base Document). The HP C++ run-
time library provides the functions needed for initialization, termination, and memory
management of C++ programs and the iostream class library.
HP Cfront accepts C++ source code accepted by USL Cfront, version 3.0. In addition,
Cfront provides support for:
• C compiler pragmas
• Large-memory model
• 32-bit data model
• Data type signed char
• Data type long long
• Source level debugging with the Inspect debugger
In the Guardian environment, support is also provided for:
• Mixed language programming using interface declarations
• Completion codes for error detection

Exception Handling Is Not Supported

Exception handling is described in The Annotated C++ Reference Manual. However,
exception handling is not implemented in either USL Cfront or HP Cfront.

Compilation Steps for C++ Code

To compile C++ code in the Guardian and OSS environments, use the following steps:
1. Run the Cprep preprocessor to provide macro and file expansion. The C
preprocessor produces C++ source code for input to Cfront.
2. Run the Cfront translator to translate the C++ source code and produce C source
code for input to the C compiler.
3. Run the C compiler to produce C object code that, when bound with the C++ run-
time library and the C run-time library, produces an executable C++ program.
4. You can optionally process the executable C++ program with the Accelerator.
In the Guardian environment, you can use a TACL macro to run the compilation
system components. In the OSS environment, the TNS c89 utility provides an
interface to the C++ compilation system components. For details, see Section 15,
Compiling, Binding, and Accelerating TNS C++ Programs.

HP C/C++ Programmer’s Guide for NonStop Systems —429301-004

1 -3
Introduction to HP C and C++ for NonStop Systems TNS/R Native C and C++ Language System

TNS/R Native C and C++ Language System

The TNS/R native C and C++ language system generates native C and C++ programs
for the Guardian and OSS environments.
Components of this language system:
• TNS/R Native C Compiler on page 1-4
• TNS/R Native C++ Compiler on page 1-5
• TNS/R Native C Run-Time Library on page 1-5
• C++ Run-time Library and Standard C++ Library on page 1-6
• TNS/R Native Linkers (nld and ld Utilities) on page 1-7
• Optional components:
° Inspect Symbolic Debugger on page 1-7
° Visual Inspect Symbolic Debugger on page 1-7
° NonStop SQL/MP Compiler and NonStop SQL/MX Compiler on page 1-9
° TNS/R Native C and C++ Migration Tool on page 1-9
TNS/R Native C Compiler
The TNS/R native C compiler accepts C language source files that comply with either
the ISO/ANSI C Standard (ISO/IEC 9899:1990, Programming Languages–C or ANSI C
X3.159-1989, Programming Language C) or Common-Usage C (sometimes called
Kernighan and Ritchie C, or K&R C). The native C compiler also accepts HP NonStop
extensions that support the native architecture.
The native C compiler can be run in the Guardian and OSS environments, and on a
PC using the HP Enterprise Toolkit, as follows:
• In the Guardian environment, use the NMC command to run the native compiler.
The NMC command line syntax is similar to that of the C command for running the
TNS C compiler. For syntax information, see Compiling a C Module on page 14-4.
• In the OSS environment, use the native c89 utility to run the native C compiler.
The native c89 utility syntax is similar to that of the TNS c89 utility. For syntax
information, see Using the c89 Utility on page 14-13.
• On a PC running the Windows operating system, use the Enterprise Toolkit (ETK)
or the Tandem Development Suite (TDS) to compile C code. You can also use the
command-line cross compiler (named c89) outside the ETK or TDS. For more
information, see the online help in the ETK or TDS, or the file “Using the
Command-Line Cross Compilers” installed with the ETK compiler package.
The native C compiler supports programs that define the size of pointers and type int
as 32 bits (programs compiled with the pragma WIDE). Existing TNS C language
programs that define pointers or type int as 16 bits must be changed. Few other C
language source code changes are required to use the native C compiler.

HP C/C++ Programmer’s Guide for NonStop Systems —429301-004

1 -4
Introduction to HP C and C++ for NonStop Systems TNS/R Native C++ Compiler

TNS/R Native C++ Compiler

There are three versions or dialects of the native C++ compiler; all three versions
accept C++ language source files and support HP language extensions. However, the
three versions support different standards as described in the descriptions of pragmas
VERSION1, VERSION2, and VERSION3.
The native C++ compiler can be run in the Guardian and OSS environments, and on a
PC using the HP Enterprise Toolkit or the Tandem Development Suite, as follows:
• In the Guardian environment, use the NMCPLUS command to run the native C++
compiler. NMCPLUS command syntax is similar to that of the C command for
running the TNS C compiler and to that of the Cfront translator. For syntax
information, see Compiling a C Module on page 14-4.
• In the OSS environment, use the native c89 utility to run the native C++ compiler.
Native c89 syntax is similar to that of the TNS c89 utility. For syntax information,
see Using the c89 Utility on page 14-13.
• On a PC running the Windows operating system, use the Enterprise Toolkit (ETK)
or the Tandem Development Suite (TDS) to compile C++ code. You can also use
the command-line cross compiler (named c89) outside the ETK or TDS. (The TDS
does not support VERSION3.) For more information, see the online help in the ETK
or TDS, or the file “Using the Command-Line Cross Compilers” installed with the
ETK compiler package.
The native C++ compiler supports programs that define the size of data type int as 32
bits (programs compiled with the pragma WIDE). Existing TNS C++ language programs
that define the type int as 16 bits must be changed. Few other C++ language source
code changes are required to use the native C++ compiler.
The native C++ compiler provides a more powerful and simplified development
environment than TNS Cfront. For example, to create an accelerated executable TNS
C++ program, you must perform five steps (running Cprep, Cfront, the TNS C compiler,
Binder, and the Accelerator). In comparison, to create an executable native C++
program, you run only the native C++ compiler and a native linker, either nld or ld.

TNS/R Native C Run-Time Library

The native C run-time library provides functions conforming to the ISO/ANSI C
Standard. It also contains functions conforming to the X/OPEN UNIX 95 specification
and HP extensions to these standards.
The native C run-time library supports Guardian and OSS processes. The native C
run-time library is nearly identical for the Guardian and OSS environments and thus
increases the interoperability between environments. For details on interoperability,
refer to the Open System Services Programmer’s Guide.
The native C run-time library provides locale-sensitive functions and algorithmic code-
set converters for use in internationalized OSS applications. For details, refer to the
Software Internationalization Guide.

HP C/C++ Programmer’s Guide for NonStop Systems —429301-004

1 -5
Introduction to HP C and C++ for NonStop Systems C++ Run-time Library and Standard C++ Library

C++ Run-time Library and Standard C++ Library

The C++ run-time library and the Standard C++ Library are available to every C++
program. However, there are three versions of the libraries, as listed here and in
Table 5-1 on page 5-1. Specifying a version establishes a context that includes the
dialect of the native C++ compiler, the run-time libraries available to you, and the
libraries that are automatically linked when you compile a runnable object file.

VERSION1 C++ Library

For C++ VERSION1 (the default version before the G06.20 RVU), the following
libraries are available:
• The HP NonStop C run-time library (ZCRTLSRL)
• The HP NonStop C++ run-time library (T9227, Guardian version ZCPLGSRL;
OSS version ZCPLOSRL)
• Tools.h++ version 6.1 (Guardian version ZTLHGSRL; OSS version ZTLHOSRL)

VERSION2 Standard C++ Library

For C++ VERSION2, the following libraries are available:
• The HP NonStop C run-time library (ZCRTLSRL)
• The HP NonStop C++ run-time library (T0179, ZCPLSRL)
• The draft Standard C++ Library from Rogue Wave (T5895, ZRWSLSRL)
• Tools.h++ version 7.0 (ZTLHSRL)

VERSION3 Standard C++ Library ISO/IEC

For C++ VERSION3 (the default version beginning with the G06.20 RVU), the following
libraries are available:
• The HP NonStop C run-time library (ZCRTLSRL)
• The VERSION3 library (T2767, ZSTLSRL), which includes:
° The HP NonStop C++ run-time library
° The ratified Standard C++ Library ISO/IEC from Dinkumware, based on the
standard document: ISO/IEC 14882:1998(E).

C++ Header Files Combined at G06.20

At the G06.20 RVU, the C++ header files for all three versions have been combined
into one product number (T2824). Built-in checking enforces the use of the correct
header files with each version. This change does not affect how you use the header
files; the change is transparent to the user.

HP C/C++ Programmer’s Guide for NonStop Systems —429301-004

1 -6
Introduction to HP C and C++ for NonStop Systems TNS/R Native Linkers (nld and ld Utilities)

TNS/R Native Linkers (nld and ld Utilities)

The nld native linker links one or more TNS/R native object files (files generated by
the native compilers or nld) to produce either an executable (a loadfile) or relinkable
native object file (linkfile). nld can also modify process attributes, such as HIGHPIN, of
executable native object files and remove nonessential information from native object
files.
The ld native linker, introduced at G06.20, performs the same basic functions as ld,
but produces PIC (Position-Independent Code), the format necessary when using
dynamic-link libraries (DLLs). If you are using DLLs, you must use ld to link your
linkfiles.
Unlike Binder, nld and ld cannot replace individual procedures and data blocks in an
object file or build an object file from individual procedures and data blocks. nld and
ld operate on procedures and data blocks, but only in terms of an entire object file.
nld and ld run in the Guardian and OSS environments as well as the HP Enterprise
Toolkit (ETK) on the PC; only nld is available with the Tandem Development Suite
(TDS). With both linkers, you can specify the target platform as either Guardian or
OSS. Command syntax and capabilities are nearly identical in each environment. To
display the syntax, enter nld or ld at the command prompt.
For more information, see:
• DLL Programmer’s Guide for TNS/R Systems
• nld and noft Manual
• ld and rld Reference Manual

Inspect Symbolic Debugger

The Inspect symbolic debugger is an interactive tool that enables you to identify and
correct programming errors in programs.
You can use Inspect to:
• Step through code
• Set breakpoints
• Display source
• Display variables
For details on debugging capabilities, see the Inspect Manual and the Debug Manual.

Visual Inspect Symbolic Debugger

Visual Inspect is an optional PC-based (GUI) symbolic debugger designed to work in
complex distributed environments. Visual Inspect:
• Supports application debugging in either the development or production
environment

HP C/C++ Programmer’s Guide for NonStop Systems —429301-004

1 -7
Introduction to HP C and C++ for NonStop Systems TNS/R Native Object File Tool (noft Utility)

• Uses program visualization, direct manipulation, and other techniques to improve

productivity for both new and sophisticated users
• Provides source-level debugging for servers executing in either the Guardian or
OSS environment; provides additional application navigation features that allow a
higher level of abstraction
• Supports both CISC and RISC machine architectures and compilers (that is, C,
C++, COBOL, TAL, pTAL, Pascal, and FORTRAN), Guardian and OSS executing
environments
• Is available also as a stand-alone product
For more information about enabling and using Visual Inspect, see the Visual Inspect
online help. See also the descriptions of pragmas INSPECT on page 13-50 and
SYMBOLS on page 13-105.

TNS/R Native Object File Tool (noft Utility)

The native object file tool (the noft utility) reads and displays information about native
object files. You can use noft to:
• Determine the optimization level of procedures
• Display object code with corresponding source code
• List object file attributes
• List unresolved references
noft runs in the Guardian and OSS environments. The noft syntax and capabilities
are nearly identical in each environment. For more information, see the nld and noft
Manual.
Native object files are in Executable and Linking Format (ELF), a standard format used
for object files, with HP extensions. For details on native object files, see the nld and
noft Manual.
A native object file is either a linkfile or a loadfile, but not both. The native compilers
produce only linkfiles, while the nld utility can produce either linkfiles or loadfiles.
Linkfiles can be used again as input to nld and ld. Loadfiles can be used as input to
nld and ld only for modifying loadfile attributes. Both linkfiles and loadfiles can be
used as noft input.

Can Be Linked to Can Be

Produce a Loadfile Executed
Linkfiles Yes No
Loadfiles No Yes

HP C/C++ Programmer’s Guide for NonStop Systems —429301-004

1 -8
Introduction to HP C and C++ for NonStop Systems NonStop SQL/MP Compiler and NonStop SQL/MX
Compiler

NonStop SQL/MP Compiler and NonStop SQL/MX Compiler

The NonStop SQL/MP compiler processes embedded SQL statements from C source
programs and generates the correct NonStop SQL/MP database calls. See the
SQL/MP Programming Manual for C.
The NonStop SQL/MX compiler, available on the OSS platform, processes embedded
SQL statements from TNS/R native C or C++ source programs and generates the
correct NonStop SQL/MX database calls. See the SQL/MX Programming Manual for C
and COBOL.

TNS/R Native C and C++ Migration Tool

The native C and C++ migration tool, NMCMT, scans source files and produces a
diagnostic listing. The listing identifies most C and C++ language source code changes
required to migrate from TNS C (D20 or later product versions) to native C or C++.
The native mode migration tool is available in both the Guardian and OSS
environments, and it is integrated into the HP Enterprise Toolkit on the PC.

Features of TNS/R Native C and C++

Over the years, TNS/R native C and C++ have evolved as the languages themselves
were changing.
• At the D40 release, the TNS/R native C/C++ compiler accepted the language as
defined by The Annotated C++ Reference Manual by Ellis and Stroustrup
(excluding support for exception handling).
• At D45, some features were updated to match the language specification in the
1996 X3J16/WG21 Working Paper. VERSION2 of the native C++ compiler is
based on the 1996 standard. The native C++ compiler introduced support for
exceptions and a number of features that are not in the The Annotated C++
Reference Manual but are new in the working paper. A summary of the major
features added at D45 appears in the description of pragma VERSION2 on
page 13-112. A list of specific features accepted from the working paper appears in
Appendix E, Features and Keywords of TNS/R Native C++.
• At G06.20, a new version or dialect of the native C++ compiler was introduced.
VERSION3 of the compiler is based on the 1998 standard, listed in the references
that follow. VERSION3 is the default library used by the native C++ compiler.
This manual is not intended to be a reference manual for ANSI C or for C++. For a
complete description of ANSI C, see ANSI X3.159. For a complete description of C++,
see ANSI X3J16/96-0225 (VERSION2) and ISO/IEC 14882:1998(E) (VERSION3).
Useful references on C and C++ include:
• ANSI C, American National Standards Institute. ANSI X3.159-1989.

HP C/C++ Programmer’s Guide for NonStop Systems —429301-004

1 -9
Introduction to HP C and C++ for NonStop Systems Features of TNS/R Native C and C++

• Ellis, Margaret A. and Stroustrup, Bjarne. The Annotated C++ Reference Manual.
Addison Wesley, 1990.
• ISO/IEC. Programming Languages – C. International Standard ISO/IEC 9899. First
edition 1990-12-15.
• Working Paper for Draft Proposed International Standard for Information Systems–
Programming Language C++. X3, Information Processing Systems. 2 Dec 1996.
X3J16/96-0225 WG21/N1043 (the standard on which the NonStop VERSION2 of
the Standard C++ Library is based).
• International Standard ISO/IEC 14882:1998(E) Programming Languages -- C++
(the 1998 standard on which the NonStop VERSION3 of the Standard C++ Library
is based).
• International Standard ISO/IEC 14882:2003(E) Programming Languages -- C++ (a
newer standard)
HP includes several extensions to ISO/ANSI standard C that make C an effective
language for writing applications that execute under the HP NonStop Kernel operating
system. Some of these features are:
• Access to several types of physical files
There is an extensive set of I/O library routines that enable you to access many
different types of physical files, including:
° C disk files, which are odd-unstructured files and have a file code of 180
° EDIT disk files, which have a file code of 101
° Processes
° Terminals
° $RECEIVE
• Two file-reference models
There are two sets of input and output routines; each set has its own method of
tracking, maintaining, and referring to a file. These methods, called file-reference
models, are:

° The ANSI model, which uses FILE pointers to identify files

° The alternate or UNIX-style model, which uses file descriptors to identify files
With two file-reference models available, you can select the model whose I/O
services best suit the needs of your application. For more details, see Section 4,
Using the C Run-Time Library.
• Access to Guardian system procedures
You can call procedures in the Guardian system library using the cextdecs
header file in the Guardian environment or the cextdecs.h header file in the OSS
environment.

HP C/C++ Programmer’s Guide for NonStop Systems —429301-004

1-10
Introduction to HP C and C++ for NonStop Systems Writing Portable Programs

• Access to Open System Services system calls and library calls

You can call routines that are part of the Open System Services library.
• Access to procedures written in other languages
TNS programs can call procedures written in C, C++, COBOL85, FORTRAN,
Pascal, and TAL. Native programs can call procedures written in C, C++, native
COBOL, and pTAL.
• Access to a NonStop SQL/MP database or a NonStop SQL/MX database
Your TNS/R native C or C++ program can interface to a NonStop SQL/MP or
NonStop SQL/MX database using embedded SQL.
• Fault-tolerant programs
You can write fault-tolerant process pairs using the active backup programming
model.

Writing Portable Programs

A portable application is an application designed using open, industry-standard
languages, application program interfaces (APIs), and middleware, such as the C
language and POSIX.1 API. A portable application can be moved between hardware
systems and middleware environments from different vendors. This subsection
provides guidelines for writing portable C programs.

Complying With Standards

Writing programs to international standards enables you to move them between
different hardware and software environments with little effort. Write your C programs
to comply with the ISO/ANSI C standard: ISO/IEC 9899:1990, Programming
Languages–C. For a complete description of ANSI C, see ANSI X3.159.
If you are writing a program to run in the Open System Services (OSS) environment,
you should also comply with the following standards:
• X/Open Common Applications Environment (CAE) Specification, System Interfaces
and Headers, Issue 4, Version 2, 1994.
• X/Open Common Applications Environment (CAE) Specification, System Interface
Definitions, Issue 4, Version 2, 1994.
• X/Open Common Applications Environment (CAE) Specification, System Interface
Definitions, Issue 4, Version 2, 1994.
• ISO/IEC 9945-1:1990, Information Technology—Portable Operating System
Interface (POSIX) — Part 1: System Application Program Interface (API)
[C Language].

HP C/C++ Programmer’s Guide for NonStop Systems —429301-004

1-11
Introduction to HP C and C++ for NonStop Systems Complying With Standards

• ISO/IEC DIS 9945-2:1992, Information Technology—Portable Operating System

Interface (POSIX) — Part 2: Shell and Utilities
The OSS environment provides all of the function calls specified in the POSIX.1
standard, and many of the function calls specified in the POSIX.2 standard and the
XPG4 specification. Before using a function that is not part of the ISO/ANSI C
standard, check to make sure that the OSS environment provides that function.
Feature-test macros enable you to check how well a program complies with these
standards. The C header files contain definitions required by the ISO/ANSI C standard,
the POSIX.1 standard, the POSIX.2 standard, the XPG4 specification, and the XPG4.2
specification. You control the visibility of these definitions with feature-test macros. If a
program does not conform to the standard or specification controlled by a feature-test
macro, the compiler issues error and warning messages.
The five feature-test macros that apply to standards compliance are:

_POSIX_C_SOURCE=1 Makes visible identifiers required or

permitted by the POSIX.1 standard.
_POSIX_C_SOURCE=2 Makes visible identifiers required or
permitted by the POSIX.1 and POSIX.2
standards.
_XOPEN_SOURCE Makes visible identifiers required or
permitted by the XPG4 specification.
Represents the OSS compile default.
_XOPEN_SOURCE_EXTENDED=1 Makes visible identifiers specified in the
XPG4.2 specification as extensions to the
XPG4 specification.
_TANDEM_SOURCE Makes visible the identifiers required or
permitted by extensions made by HP.
Represents the Guardian compile default for
the TNS C compiler. Includes some of the
identifiers required by the XPG4
specification, as well as POSIX.1 and
POSIX.2 standards.
The XPG4 specification includes the identifiers required by the POSIX.1 and POSIX.2
standards. Thus, specifying the _XOPEN_SOURCE macro automatically includes the
identifiers included by the _POSIX_C_SOURCE=2 macro.
For more information about feature-test macros, see Feature-Test Macros on
page 12-13.

HP C/C++ Programmer’s Guide for NonStop Systems —429301-004

1-12
Introduction to HP C and C++ for NonStop Systems Following Good Programming Practices

Following Good Programming Practices

In general, the more you follow good programming practices, the easier it will be to port
your program to other hardware and software environments. A few of the most
important good programming practices are:
• Use strictly conforming C language features as described in the ISO/ANSI C
standard as much as possible. Isolate HP defined and extended C language
features into specific modules.
• Use function prototypes.
• Place all environment-specific function declarations in a common header file, such
as environh.
• Make sure the type of a function’s actual and formal parameters are the same.
• Define every function with an explicit return type. Make sure the type of a return
expression is the same as the return type of the function.
• Write your programs to a template similar to the following:

° Feature-test macros
° System headers
° Local headers
° Macros
° File scope variables
° External variables
° External functions
° Structures and unions
° Signal-catching functions
° Functions
° main function
• Do not write code that relies on processor architecture. Be careful when writing
code that relies on word size, pointer size, bit fields, arithmetic precision, byte
order, stack size, stack growth, heap size, and heap growth.
• Do not make assumptions about the size and format of any data type:

° Use type short and type long instead of type int, if possible. In particular,
do not interchange between type int and type long.

° Do not assign an int to or from a pointer without an explicit type cast.

° Do not assume that different pointer types are the same.

• Use unsigned types for bit fields.
There are many commercially available texts that describe how to write portable
applications in C, including:

HP C/C++ Programmer’s Guide for NonStop Systems —429301-004

1-13
Introduction to HP C and C++ for NonStop Systems Following Good Programming Practices

• Horton, Mark. Portable C Software. Prentice Hall, Inc., 1990.

• Jaeschke, Rex. Portability and the C Language. Hayden Books, 1989.
• Lapin, J. E. Portable C and UNIX System Programming. Rabbit Software, 1987.
• Rabinowitz, Henry, and Chaim Schaap. Portable C. Prentice Hall, Inc., 1989.

HP C/C++ Programmer’s Guide for NonStop Systems —429301-004

1-14
Introduction to HP C and C++ for NonStop Systems Porting Programs to HP C and C++ for NonStop
Systems

Porting Programs to HP C and C++ for

NonStop Systems
HP C complies with the ISO/ANSI C standard. Any C program that strictly conforms
with this standard and does not use features beyond this standard can immediately be
compiled in HP C. Programs written in Common-Usage C (also called Kernighan and
Ritchie C or K&R C) can also be compiled with the native C compiler.
For information on porting UNIX C and C++ programs to Open System Services, refer
to the Open System Services Porting Guide.
It is impossible to provide a complete set of guidelines on porting programs to
ISO/ANSI C, but most porting issues have one of two solutions:
• Replace nonstandard function calls with one or more functions from the ISO/ANSI
C standard. In the OSS environment, you can also use many function calls defined
in the POSIX.1 and POSIX.2 standards and the XPG4 specification.
• Redesign the code to use functions and features of ISO/ANSI C.
Many UNIX compilers now comply with the ISO/ANSI C standard. Unlike the HP C
compilers, most of these compilers do not strictly enforce the standard by default.
These compilers allow features that do not comply with the standard but that the
compilers can still process correctly. Thus, many programs that you thought to be
compliant are not.
To compile standard-compliant programs with the native C compiler, specify the
pragma KR (for Kernighan & Ritchie or Common-Usage C). To compile such programs
with the TNS C compiler, first convert the programs to ISO/ANSI C in their original
environment. The documentation for these compilers often describes the specific
changes required to make a program comply with ISO/ANSI C.
The following commercially available texts describe writing programs that comply with
the ISO/ANSI C standard and porting from Common-Usage C to ISO/ANSI C:
• Harbison, Samuel P. and Guy L. Steele. C, A Reference Manual. Prentice Hall,
Inc., 1991.
• Kernighan, Brian W. and Dennis M. Ritchie. The C Programming Language.
Prentice Hall, Inc., 1988.
• Strake, David. C Style: Standards and Guidelines. Prentice Hall, Inc., 1992.
• ANSI C Transition Guide. Prentice Hall, Inc., 1990.

HP C/C++ Programmer’s Guide for NonStop Systems —429301-004

1-15
Introduction to HP C and C++ for NonStop Systems Guardian and OSS Environment Interoperability

Guardian and OSS Environment

Interoperability
Open System Services (OSS) is an alternative to the Guardian interface through which
users and programs can interact with the NonStop Kernel operating system. The main
purpose of Open System Services is to provide an open interface to the operating
system for supporting portable applications.
An application program can be compiled to run in either the OSS or Guardian
environment and can use services from each environment, including the API, tools,
and utilities. The interoperability enables you to:
• Compile and link OSS programs in the Guardian environment
• Compile and link Guardian programs in the OSS environment
• Call most Guardian C functions and Guardian system procedures from OSS
programs
• Call most OSS functions from Guardian programs
You do not need to do anything special for programs that manipulate objects
exclusively in the environment in which they run. However, the NonStop Kernel
enables you to write programs that manipulate objects in both the Guardian and OSS
environments.
For TNS C programs, Guardian and OSS C run-time interoperability is supported for
programs using only the 32-bit or wide data model. Interoperability is not supported for
TNS C programs using the 16-bit data model. Interoperability is supported for all native
programs, because native C programs support only the 32-bit or wide data model.
At D44, some interoperable modules require code changes and recompilation. For
details and instructions, see Changes Required to Interoperable Compilation Modules
at D44 on page 4-10.
For details on Guardian and OSS interoperability, refer to the Open System Services
Programmer’s Guide.

HP C/C++ Programmer’s Guide for NonStop Systems —429301-004

1-16