Open System Services Programmer's Guide
C API Interoperability in Native Processes
This appendix contains the API Interoperability tables, which describe the interoperability between
the Guardian API and the OSS API in TNS/R and TNS/E native processes.
These tables list the functions and macros in the native C Run-Time Library and the OSS API.
Functions in the Guardian sockets library and Guardian system procedures are not included.
The tables indicate the following characteristics for each function or macro:
• Modules it can be called from
• Processes it can be called from
• Parameters it requires
• Objects it can operate on
Comparing API Interoperability in TNS and Native Processes
The native C run-time library supports both the OSS and Guardian environments. Having a single
library for functions that are part of both APIs means that most differences in behavior that exist in
TNS processes do not exist in native processes.
For example, in TNS processes the signal() function can be called only from a Guardian module
within a Guardian process or from an OSS module within an OSS process. The Guardian function
operates only on Guardian objects, and the OSS function operates only on OSS objects. None
of these differences in behavior of the signal() function exist in native processes.
There are still some functions, however, such as fopen() and rename(), that have
environment-specific behavior and require environment-specific parameters.
In addition, for the native C run-time library:
• Eight functions that require environment-specific parameters have environment-specific variants.
These functions are fopen(), fopen64(), freopen(), freopen64(), remove(),
rename(), tmpnam(), and tmpfile(). The environment-specific variants of these functions
have suffixes, such as fopen_guardian() and fopen_oss(). For example, you can use
fopen_oss() to open an OSS file from within a Guardian process.
• There are no separate Guardian variants of functions that operate on file descriptors instead
of streams. For example, the open() and read() functions can be accessed from both the
Guardian and OSS environments, but always operate on OSS file descriptors.
• Some functions that are specified by HP have been eliminated, such as readupdate() and
edlseek().
• Some functions, such as erf() and strdup(), have been added to the native library for
compliance to the XPG4 specification.
For a detailed description of the differences between the TNS and TNS/R or TNS/E native C
run-time libraries, see the TNS/R Native Application Migration Guide or the TNS/E Native
Application Conversion Guide.
Calling Functions and Macros
The two factors that determine when you can call a function or macro are:
• The environment for which the module containing the call was compiled.
• The environment of the process executing the module.
An OSS module is a module compiled to have OSS semantics and execute in the OSS environment.
Likewise, a Guardian module is a module compiled to have Guardian semantics and execute in
the Guardian environment. Normally, the environments of a module and the process executing the
module are the same.
You can mix modules of different environments in the same process. An OSS process can execute
both OSS and Guardian modules, and a Guardian process can execute both Guardian and OSS
500 API Interoperability in Native Processes