HP OpenVMS Systems Documentation

Content starts here

Run-Time Library Reference Manual for OpenVMS Systems

Previous Contents Index

Chapter 1

The ISO/ANSI C standard defines a library of functions, as well as related types and macros, to be provided with any implementation of ANSI C. The HP C Language Reference Manual describes the ANSI-conformant library features common to all HP C platforms. The HP C Run-Time Library Reference Manual for OpenVMS Systems provides a more detailed description of these routines and their use in the OpenVMS environment. It also documents additional header files, functions, types, and macros that are available on the OpenVMS system.

All library functions are declared in a header file. To make the contents of a header file available to your program, include the header file with an #include preprocessor directive. For example:

#include <stdlib.h> 

Each header file contains function prototypes for a set of related functions, and defines any types and macros needed for their use.

To list the header files on OpenVMS Alpha or Integrity server systems, use the following commands:


The first command lists the text module form of the header files for the OpenVMS system interfaces. The second lists the text module form of the header files for the HP C language interface. The third lists *.H header files for the HP C language interfaces. The fourth lists *.H header files for layered products and other applications.


The SYS$COMMON:[DECC$LIB.REFERENCE.DECC$RTLDEF] directory is only a reference area for your viewing. The compiler still looks in the *.TLB files for #include file searches.

However, duplicate files (such as <stdio.h> ) found in SYS$LIBRARY probably support the VAX C Version 3.2 environment and should not be used with HP C.

Function definitions themselves are not included in the header files, but are contained in the HP C Run-Time Library (RTL) shipped with the OpenVMS operating system. Before using the HP C RTL, you must be familiar with the following topics:

  • The linking process
  • The macro substitution process
  • The difference between function definitions and function calls
  • The format of valid file specifications
  • The OpenVMS-specific methods of input and output (I/O)
  • The HP C for OpenVMS extensions and nonstandard features

A knowledge of all these topics is necessary to effectively use the HP C RTL. This chapter shows the connections between these topics and the HP C RTL. Read this chapter before any of the other chapters in this manual.

The primary purpose of the HP C RTL is to provide a means for C programs to perform I/O operations; the C language itself has no facilities for reading and writing information. In addition to I/O support, the HP C RTL also provides a means to perform many other tasks.

Chapters 2 through 11 describe the various tasks supported by the HP C RTL. The Reference Section alphabetically lists and describes all the functions and macros available to perform these tasks.

1.1 Using the HP C Run-Time Library

When working with the HP C RTL, you must be aware of some implementation specifics.

First, if you plan to use HP C RTL functions in your C programs, make sure that a function named main or a function that uses the main_program option exists in your program. For more information, see the HP C Language Reference Manual or the HP C User's Guide for OpenVMS Systems.

Second, the HP C RTL functions are executed at run time, but references to these functions are resolved at link time. When you link your program, the OpenVMS linker resolves all references to HP C RTL functions by searching any shareable code libraries or object code libraries specified on the LINK command line.

You can use the HP C RTL as a shareable image or you can use the HP C RTL object libraries.

When you use the HP C RTL as a shareable image, the code for the RTL resides in an image file in SYS$SHARE and is shared by all HP C programs. After execution, control returns to your program. This process has a number of advantages:

  • You reduce the size of a program's executable image.
  • The program's image takes up less disk space.
  • The program swaps in and out of memory faster due to decreased size.
  • With HP C and HP C++, you no longer need to define an options file when linking your program against the shareable image. Linking against the RTL shareable image is now much simpler than it was with VAX C. In fact, it is the default method of linking to the HP C RTL.

When linking to the HP C RTL, you do not need to define any LNK$LIBRARY logicals. In fact, you should deassign LNK$LIBRARY because linking with the shareable image is more convenient than linking with the HP C RTL object libraries.

See your OpenVMS, HP C, or HP C++ release notes for any supplemental information about linking with the HP C RTL.

1.2 RTL Linking Options

The following sections describe several ways of linking HP C and HP C++ programs with the HP C RTL on OpenVMS Alpha and Integrity server systems.

1.2.1 Linking with the Shareable Image

Most linking needs should be satisfied by using the HP C RTL shareable image DECC$SHR.EXE in the ALPHA$LIBRARY (ALPHA ONLY) or IA64$LIBRARY (INTEGRITY SERVERS ONLY) directory.

The shareable images VAXCRTL.EXE and VAXCRTLG.EXE do not exist on OpenVMS Alpha and Integrity server systems. The only C RTL shareable image is ALPHA$LIBRARY:DECC$SHR.EXE (ALPHA ONLY) or IA64$LIBRARY:DECC$SHR.EXE (INTEGRITY SERVERS ONLY) , which the linker automatically finds through IMAGELIB.OLB.

The fact that VAXCRTL*.EXE does not exist on Alpha and Integrity server systems has the following ramifications:

  • You must change any existing VAX C link procedures to eliminate any references to the VAXCRTL*.EXE images. An explicit reference to DECC$SHR.EXE is unnecessary because IMAGELIB.OLB is searched automatically by the linker (see the HP OpenVMS Linker Utility Manual).
  • Because DECC$SHR.EXE exports only prefixed universal symbols (ones that begin with DECC$), to successfully link against it make sure you cause prefixing to occur for all HP C RTL entry points that you use.
    If you use only the HP C RTL functions defined in the ANSI C Standard, all entry points will be prefixed.
    If you use HP C RTL functions not defined in the ANSI C Standard, you must compile in one of two ways to ensure prefixing:
    • Compile with the /PREFIX_LIBRARY_ENTRIES=ALL_ENTRIES qualifier.
    • Compile with the /STANDARD=VAXC or /STANDARD=COMMON qualifier; you get /PREFIX_LIBRARY_ENTRIES=ALL_ENTRIES as the default.

To link against the shareable image, use the LINK command. For example:


The linker automatically searches IMAGELIB.OLB to find DECC$SHR.EXE, and resolves all C RTL references.

1.2.2 Linking with the Object Libraries (ALPHA ONLY)

The HP C RTL object libraries on OpenVMS Alpha systems are used solely for linking programs compiled without /PREFIX=ALL. Please note that these object libraries do not exist on OpenVMS Integrity server systems.

On OpenVMS Alpha systems, the HP C RTL provides the following object libraries in the ALPHA$LIBRARY directory:


The object library VAXCCURSE.OLB, which provides access to the Curses functions, contains unprefixed entry points that vector to the appropriate prefixed entry points.

The object libraries VAXCRTL.OLB, VAXCRTLD.OLB, VAXCRTLT.OLB, VAXCRTLX.OLB, VAXCRTLDX.OLB, and VAXCRTLTX.OLB also contain unprefixed entry points that vector to the appropriate prefixed entry points, depending on the floating-point type specified by the object library used:

  • VAXCRTL.OLB contains all HP C RTL routine name entry points as well as VAX G-floating double-precision, floating-point entry points.
  • VAXCRTLD.OLB contains a limited support of VAX D-floating double-precision, floating-point entry points.
  • VAXCRTLT.OLB contains IEEE T-floating double-precision, floating-point entry points.
  • VAXCRTLX.OLB contains G_floating support and support for the /L_DOUBLE_SIZE=128 compiler qualifier.
  • VAXCRTLDX.OLB contains D_floating support and support for the /L_DOUBLE_SIZE=128 compiler qualifier.
  • VAXCRTLTX.OLB contains IEEE T_floating support and support for the /L_DOUBLE_SIZE=128 compiler qualifier.

/L_DOUBLE_SIZE=128 is the default.

On the LINK command, specify only one of the VAXCRTL*.OLB libraries and, if needed, the VAXCCURSE.OLB library.

In the default mode of the compiler (/STANDARD=RELAXED_ANSI89) and also in strict ANSI C mode, all calls to ANSI C standard library routines are automatically prefixed with DECC$. With the /[NO]PREFIX_LIBRARY_ENTRIES qualifier, you can change this to prefix all HP C RTL names with DECC$, or to not prefix any HP C RTL names. Other options are also available for this qualifier. See the /[NO]PREFIX_LIBRARY_ENTRIES qualifier in this chapter for more information.

When linking with /NOSYSSHR, if calls to the HP C RTL routines are prefixed with DECC$, then the modules in STARLET.OLB are the only ones you need to link against. Since STARLET.OLB is automatically searched by the linker (unless the link qualifier /NOSYSLIB is used), all prefixed RTL external names are automatically resolved.

If any calls to the HP C RTL routines are not prefixed, then you need to explicitly link against VAXCRTL.OLB, VAXCRTLD.OLB, VAXCRTLT.OLB (or VAXCRTLX.OLB, VAXCRTLDX.OLB, or VAXCRTLDX.OLB), or VAXCCURSE.OLB, depending on which floating-point types you need, or if you want Curses functions. If you are linking with /NOSYSSHR, prefixed HP C RTL entry points are resolved in STARLET.OLB. If you are linking with /SYSSHR (the default), prefixed HP C RTL entry points are resolved in DECC$SHR.EXE.

1.2.3 Examples

The following examples show several different ways you might want to link with the HP C RTL. See Figure 1-1 for a graphical summary of these examples.

  1. Most of the time, you just want to link against the shareable image:

    $ LINK PROG1

    The linker automatically searches IMAGELIB.OLB to find DECC$SHR.EXE.
  2. If you want to use just object libraries (to write privileged code or for ease of distribution, for example), use the /NOSYSSHR qualifier of the LINK command:


    Prefixed RTL symbol references in the user program are resolved in the HP C RTL object library contained in STARLET.OLB.


    • When linking HP C programs against the HP C RTL object libraries using the /NOSYSSHR qualifier, applications that previously linked without undefined globals may result in undefined globals for the CMA$TIS symbols. To resolve these undefined globals, add the following line to your link options file:

    • If a program linked with the /NOSYSSHR qualifier makes a call to a routine that resides in a dynamically activated image, and the routine returns a value indicating an unsuccessful status, errno is set to ENOSYS, and vaxc$errno is set to C$_NOSYSSHR. The error message corresponding to C$_NOSYSSHR is "Linking /NOSYSSHR disables dynamic image activation." An example of this situation is a program linked with /NOSYSSHR that makes a call to a socket routine.
  3. (ALPHA ONLY). On OpenVMS Alpha systems, when compiling with prefixing disabled, in order to use object libraries that provide alternate implementations of C RTL functions, you need to use the VAXC*.OLB object libraries. In this case, compile and link as follows:


    Unprefixed HP C RTL symbol references in the user program are resolved in MYLIB and in VAXCRTL.OLB.
    Prefixed HP C RTL symbol references in VAXCRTLX.OLB are resolved in DECC$SHR.EXE through IMAGELIB.OLB.
    In this same example, to get IEEE T-floating double-precision floating-point support, you might use the following compile and link commands:

  4. (ALPHA ONLY). Combining examples 2 and 3, you might want to use just the object libraries (for writing privileged code or for ease of distribution) and use an object library that provides C RTL functions. In this case, compile and link as follows:


    Prefixed HP C RTL symbol references in VAXCRTL.OLB are resolved in STARLET.OLB.

Figure 1-1 Linking with the HP C RTL on OpenVMS Alpha and Integrity server Systems

1.2.4 DECC$SHRP.EXE Image

OpenVMS installs a new shareable image DECC$SHRP.EXE to implement C RTL functions requiring protected mode. This shareable image is installed on all Alpha and Integrity server processors and is invoked from either the DECC$SHR.EXE or DECC$SHR_EV56.EXE shareable image.

1.3 HP C RTL Function Prototypes and Syntax

After learning how to link object modules and include header files, you must learn how to reference HP C functions in your program. The remaining chapters in this manual provide detailed descriptions of the HP C RTL functions.

1.3.1 Function Prototypes

In all chapters, the syntax describing each function follows the standard convention for defining a function. This syntax is called a function prototype (or just prototype). The prototype is a compact representation of the order of a function's arguments (if any), the types of the arguments, and the type of the value returned by a function. We recommend the use of prototypes.

If the return value of the function cannot be easily represented by a C data-type keyword, look for a description of the return values in the explanatory text. The prototype descriptions provide insight into the functionality of the function. These descriptions may not describe how to call the function in your source code.

For example, consider the prototype for the feof function:

#include <stdio.h>
int feof(FILE *file_ptr);

This syntax shows the following information:

  • The feof prototype resides in the <stdio.h> header file. To use feof , you must include this header file. (Declaring HP C RTL functions yourself is not recommended.)
  • The feof function returns a value of data type int .
  • There is one argument, file_ptr, that is of type "pointer to FILE". FILE is defined in the <stdio.h> header file.

To use feof in a program, include <stdio.h> anywhere before the function call to feof , as in the following example:

#include <stdio.h>                 /* Include Standard I/O     */ 
    FILE *infile;                  /* Define a file pointer    */ 
       .                           /* Call the function feof   */ 
    while ( ! feof(infile) )       /* Until EOF reached        */ 
       {                           /* Perform file operations  */ 

1.3.2 Syntax Conventions for Function Prototypes

Since some library functions take a varying number of parameters, syntax descriptions for function prototypes adhere to the following conventions:

  • Ellipses (...) are used to indicate a varying number of parameters.
  • In cases where the type of a parameter may vary, its type is not shown in the syntax.

Consider the printf syntax description:

#include <stdio.h>
int printf(const char *format_specification, ...);

The syntax description for printf shows that you can specify one or more optional parameters. The remaining information about printf parameters is in the description of the function.

1.3.3 UNIX Style File Specifications

The HP C RTL functions and macros often manipulate files. One of the major portability problems is the different file specifications used on various systems. Since many C applications are ported to and from UNIX systems, it is convenient for all compilers to be able to read and understand UNIX system file specifications.

The following file specification conversion functions are included in the HP C RTL to assist in porting C programs from UNIX systems to OpenVMS systems:

  • decc$match_wild
  • decc$translate_vms
  • decc$fix_time
  • decc$to_vms
  • decc$from_vms

The advantage of including these file specification conversion functions in the HP C RTL is that you do not have to rewrite C programs containing UNIX system file specifications. HP C can translate most valid UNIX system file specifications to OpenVMS file specifications.

Please note the differences between the UNIX system and OpenVMS file specifications, as well as the method used by the RTL to access files. For example, the RTL accepts a valid OpenVMS specification and most valid UNIX file specifications, but the RTL cannot accept a combination of both. Table 1-1 shows the differences between UNIX system and OpenVMS system file specification delimiters.

Table 1-1 UNIX and OpenVMS File Specification Delimiters
Description OpenVMS System UNIX System
Node delimiter :: !/
Device delimiter : /
Directory path delimiter [ ] /
Subdirectory delimiter [ . ] /
File extension delimiter . .
File version delimiter ; Not applicable

For example, Table 1-2 shows the formats of two valid specifications and one invalid specification.

Table 1-2 Valid and Invalid UNIX and OpenVMS File Specifications
System File Specification Valid/Invalid
UNIX beatle!/usr1/mccartney/songs.lis Valid
--- BEATLE::DBA0:[MCCARTNEY.C]/songs.lis Invalid

When HP C translates file specifications, it looks for both OpenVMS and UNIX system file specifications. Consequently, there may be differences between how HP C translates UNIX system file specifications and how UNIX systems translate the same UNIX file specification.

For example, if the two methods of file specification are combined, as in Table 1-2, HP C RTL can interpret [MCCARTNEY.C]/songs.lis as either [MCCARTNEY]songs.lis or [C]songs.lis. Therefore, when HP C encounters a mixed file specification, an error occurs.

UNIX systems use the same delimiter for the device name, the directory names, and the filename. Due to the ambiguity of UNIX file specifications, HP C may not translate a valid UNIX system file specification according to your expectations.

For instance, the OpenVMS system equivalent of /bin/today can be either [BIN]TODAY or [BIN.TODAY]. HP C can make the correct interpretation only from the files present. If a file specification conforms to UNIX system filename syntax for a single file or directory, it is converted to the equivalent OpenVMS filename if one of the following conditions is true:

  • If the specification corresponds to an existing OpenVMS directory, it is converted to that directory name. For example, /dev/dir/sub is converted to DEV:[DIR.SUB] if DEV:[DIR.SUB] exists.
  • If the specification corresponds to an existing OpenVMS filename, it is converted to that filename. For example, /dev/dir/file is converted to DEV:[DIR]FILE if DEV:[DIR]FILE exists.
  • If the specification corresponds to a nonexistent OpenVMS filename, but the given device and directory exist, it is converted to a filename. For example, /dev/dir/file is converted to DEV:[DIR]FILE if DEV:[DIR] exists.


Beginning with OpenVMS Version 7.3, you can instruct the HP C RTL to interpret the leading part of a UNIX style file specification as either a subdirectory name or a device name.

As with previous releases, the default translation of foo/bar (UNIX style name) is FOO:BAR (OpenVMS style device name).

To request translation of foo/bar (UNIX style name) to [.FOO]BAR (OpenVMS style subdirectory name), define the logical name DECC$DISABLE_TO_VMS_LOGNAME_TRANSLATION to ENABLE. DECC$DISABLE_TO_VMS_LOGNAME_TRANSLATION is checked only once per image activation, not on a file-by-file basis. Defining this logical affects not only the decc$to_vms function, but all HP C RTL functions that accept both UNIX style and OpenVMS style filenames as an argument.

In the UNIX system environment, you reference files with a numeric file descriptor. Some file descriptors reference Standard I/O devices; some descriptors reference actual files. If the file descriptor belongs to an unopened file, the HP C RTL opens the file. HP C equates file descriptors with the following OpenVMS logical names:

File Descriptor OpenVMS Logical Meaning
0 SYS$INPUT Standard input
1 SYS$OUTPUT Standard output
2 SYS$ERROR Standard error

Previous Next Contents Index