4.8.2 Program Sections Created by HP C

If necessary, HP C creates the following program sections:

• $CODE (VAX ONLY)---Contains all executable code and constant data (including variables defined with the readonly modifier or const type qualifier).
• $CODE$ (ALPHA, I64)---Contains all executable code.
• $READONLY$ (ALPHA, I64)---Contains all constant data defined with the readonly modifier or const type qualifier.
• $DATA (VAX ONLY) or $DATA$ (ALPHA, I64)---Contains all static variables, as well as global variables defined without the readonly modifier or const type qualifier. $DATA also contains character-string constants when /ASSUME=WRITABLE_STRING_LITERALS is specified.
• $LITERAL$ (ALPHA, I64)---Contains character-string constants when /ASSUME=NOWRITABLE_STRING_LITERALS is specified.
• HP C also creates additional program sections for variables declared with the globaldef keyword if the optional psect name in braces is specified, or for variables declared with the extern storage class, depending on the external model.

All program sections created by HP C have the PIC, REL, RD, USR, and NOVEC attributes. On VAX systems, the $CODE psect is aligned on a byte boundary; all other psects generated by HP C are aligned on longword boundaries. On OpenVMS Alpha and I64 systems, all psects generated by HP C are aligned on octaword boundaries. Note that use of the _align storage-class modifier can cause a psect to be aligned on greater than a longword boundary on OpenVMS VAX systems. The $CHAR_STRING_CONSTANTS psect has the same attributes as the $DATA (VAX ONLY) and $DATA$ (ALPHA, I64) psects.

Tables 4-4, 4-5, 4-6, and 4-7 summarize the differences in psects created by different declarations:

• Table 4-4, Table 4-5 (ALPHA, I64), and Table 4-6 (VAX ONLY) show different cases of variable definitions and assign to them a storage-class code number:
  • Table 4-4 shows the effect of each #pragma extern_model preprocessor directive on the storage-class code number for external variable definitions that have an extern storage class.
  • Table 4-5 shows the storage-class code number for variable definitions that do not have the extern storage class on OpenVMS Alpha and I64 systems.
  • Table 4-6 shows the storage-class code number for variable definitions that do not have the extern storage class on VAX systems.
• Table 4-7 shows the psect name and attributes associated with each storage-class code number from Tables 4-4, 4-5, and 4-6.

Table 4-4 External Models and Definitions

Storage- Class Code	External Object Definition	Interpretation
External Model: pragma extern_model common_block noshr
1	int name;	/* uninitialized definition */
1	int name = 1;	/* initialized definition */
1	extern int name;	/* treated as an uninitialized definition */
2	const int name;	/* uninitialized definition */
2	const int name = 1;	/* initialized definition */
2	extern const int name;	/* treated as an uninitialized definition */
External Model: pragma extern_model common_block shr
3	int name;	/* uninitialized definition */
3	int name = 1;	/* initialized definition */
3	extern int name;	/* treated as an uninitialized definition */
4	const int name;	/* uninitialized definition */
4	const int name = 1;	/* initialized definition */
4	extern const int name;	/* treated as an uninitialized definition */
External Model: pragma extern_model relaxed_refdef noshr
5	int name;	/* uninitialized definition */
1	int name = 1;	/* initialized definition */
6	const int name;	/* uninitialized definition */
2	const int name = 1;	/* initialized definition */
External Model: pragma extern_model relaxed_refdef shr
7	int name;	/* uninitialized definition */
3	int name = 1;	/* initialized definition */
8	const int name;	/* uninitialized definition */
4	const int name = 1;	/* initialized definition */
External Model: pragma extern_model strict_refdef
9 (ALPHA, I64)	int symbol;	/* uninitialized definition */
10 (VAX ONLY)	int symbol;	/* uninitialized definition */
10	int symbol = 1;	/* initialized definition */
11	const int symbol;	/* uninitialized definition */
11	const int symbol = 1;	/* initialized definition */
External Model: pragma extern_model strict_refdef "name" noshr
12	int symbol;	/* uninitialized definition */
12	int symbol = 1;	/* initialized definition */
13	const int symbol;	/* uninitialized definition */
13	const int symbol = 1;	/* initialized definition */
External Model: pragma extern_model strict_refdef "name" shr
14	int symbol;	/* uninitialized definition */
14	int symbol = 1;	/* initialized definition */
15	const int symbol;	/* uninitialized definition */
15	const int symbol = 1;	/* initialized definition */

Table 4-5 Combinations of Storage-Class Specifiers and Modifiers (ALPHA, I64)

Storage- Class Code	Storage-Class Keyword Combination	/SHARE or /NOSHARE	Initialized or Not
9	static	Either	No
10	static	Either	Yes
11	static const 1	Either	Either
9	globaldef	Either	No
10	globaldef	Either	Yes
11	globaldef const 1	Either	Either
14	globaldef{"name"}	/SHARE	Either
12	globaldef{"name"}	/NOSHARE	Either
15	globaldef{"name"} const 1	/SHARE	Either
13	globaldef{"name"} const 1	/NOSHARE	Either

Table 4-6 Combinations of Storage-Class Specifiers and Modifiers (VAX ONLY)

Storage- Class Code	Storage-Class Keyword Combination	/SHARE or /NOSHARE
10	static	Either
11	static const 1	Either
10	globaldef	Either
11	globaldef const 1	Either
14	globaldef{"name"}	/SHARE
12	globaldef{"name"}	/NOSHARE
15	globaldef{"name"} const 1	/SHARE
13	globaldef{"name"} const 1	/NOSHARE

Table 4-7 shows the psect name and psect attributes for the storage-class code numbers from Table 4-4, Table 4-5, and Table 4-6. Where name is used for the psect name in Table 4-7, the name of the psect is the same as name in the declarations or pragmas in Table 4-4, or the quoted brace-enclosed names in Tables 4-5 and 4-6.

Table 4-7 Combination Attributes

Storage- Class Code	Program Section Name	Program Attributes
1	name	OVR, GBL, NOSHR, NOEXE, WRT, NOCOM
2	name	OVR, GBL, NOSHR, NOEXE, NOWRT, NOCOM
3	name	OVR, GBL, SHR, NOEXE, WRT, NOCOM
4	name	OVR, GBL, SHR, NOEXE, NOWRT, NOCOM
5	name	OVR, GBL, NOSHR, NOEXE, WRT, COM
6	name	OVR, GBL, NOSHR, NOEXE, NOWRT, COM
7	name	OVR, GBL, SHR, NOEXE, WRT, COM
8	name	OVR, GBL, SHR, NOEXE, NOWRT, COM
9	$BSS$	CON, LCL, NOSHR, NOEXE, WRT, NOCOM
10	$DATA (VAX ONLY)	CON, LCL, NOSHR, NOEXE, WRT, NOCOM
10	$DATA$ (ALPHA, I64)	CON, LCL, NOSHR, NOEXE, WRT, NOCOM
11	$CODE (VAX ONLY)	CON, LCL, SHR, EXE, NOWRT, NOCOM
11	$READONLY$ (ALPHA, I64)	CON, LCL, SHR, NOEXE, NOWRT, NOCOM
12	"name"	CON, GBL, NOSHR, NOEXE, WRT, NOCOM
13	"name"	CON, GBL, NOSHR, NOEXE, NOWRT, NOCOM
14	"name"	CON, GBL, SHR, NOEXE, WRT, NOCOM
15	"name"	CON, GBL, SHR, NOEXE, NOWRT, NOCOM

The combined use of the readonly and noshare modifiers is ignored by the compiler in the following declarations:

readonly noshare static int x; readonly noshare globaldef int x;

When it encounters a situation as shown in the previous example, the compiler ignores the noshare modifier and accepts readonly. The order of the storage-class specifier, the storage-class modifier, and the data-type keyword within a declaration is not significant.

The HP C compiler does static (global) initialization of pointers by using the .ADDRESS directive. By using this mechanism, the compiler efficiently generates position-independent code. The linker makes image sections that contain such initialization nonshareable.

The HP C preprocessor provides the ability to perform macro substitution, conditional compilation, and inclusion of named files. Preprocessor directives, lines beginning with # and possibly preceded by white space, are used to communicate with the preprocessor. The HP C Language Reference Manual describes the standard-conforming preprocessor directives available with the HP C compiler. This chapter describes the preprocessor directives that are either specific to HP C on OpenVMS systems, or that are used in an implementation-specific way:

• The #dictionary directive, used for CDD/Repository extraction ( Section 5.4.3, Section 5.1)
• The #include directive, used for file inclusion ( Section 5.2)
• The #module directive, for specifying an alternative name and identification for the object module ( Section 5.3, Section 5.4.15)
• The #pragma directive and pragmas specific to OpenVMS systems ( Section 5.4)

If you plan to port programs to and from other C implementations, take care in choosing which preprocessor directives to use within your programs. See the HP C Language Reference Manual for more information about using preprocessor directives for conditional compilation. For a complete discussion of portability concerns, see the HP C Run-Time Library Reference Manual for OpenVMS Systems.

Preprocessor directives are independent of the usual scope rules; they remain in effect from their occurrence until the end of the compilation unit. For more information about the compilation unit, see Chapter 1.

5.1 CDD/Repository Extraction (#dictionary)

The #dictionary directive is retained for compatibility with VAX C, and is supported only when running HP C in VAX C mode (/STANDARD=VAXC). See Section 5.4.3 for information on using the standard C equivalent #pragma dictionary directive.

5.2 File Inclusion (#include)

The #include directive inserts external text into the source stream delivered to the compiler. This directive is often used to include global definitions for use with HP C functions and macros in the program text.

The #include directive is supported on all HP C implementations, but the syntax and semantics vary. For example, the directory search algorithm for locating included files on OpenVMS systems differs from that on Tru64 UNIX systems, primarily because of differences in the native file systems and conventions on the two platforms. Nevertheless, by choosing the lowest common denominator of plain text files in directories to contain header files, you can define command-line options for both platforms to cause searching to be done in the same way. HP C for OpenVMS Systems also provides a form of the #include directive specifically for including text modules from OpenVMS text library files. The following sections describe the #include directive as implemented on OpenVMS systems.

The #include directives may be nested to a depth determined by the FILLM process quota and by virtual memory restrictions. The HP C compiler imposes no inherent limitation on the nesting level of inclusion.

OpenVMS and most UNIX style file specifications can be included in HP C source programs.

The following sections describe the different forms of the #include directive.

5.2.1 Inclusion Using Angle Brackets

The first form of the #include preprocessor directive uses angle brackets (<>) to delimit the file specification:

#include <file-spec>

The file-spec is a valid file specification or a logical name. A file specification may be up to 255 characters long.

If the file-spec contains "/" or "!" characters, it is assumed to be a UNIX style name, and the compiler attempts to combine it with other UNIX style names from the /INCLUDE_DIRECTORY command-line qualifier and translate the result to an OpenVMS file specification using RTL functions. Otherwise, the file-spec is treated as an OpenVMS file specification with defaults supplied from command-line qualifiers and logical names in a prescribed search order.

When specifying the names of files to be included in your source program, avoid directory specifications of the following form:

DBA0:[.dir-name...]

Depending on device logical names is not good practice. Instead, try to use only simple file names complete with the .h file type, and use the /INCLUDE_DIRECTORY qualifier to specify the directories to search.

For the angle-bracket form of inclusion, the compiler searches directories in the following order for the file to be included:

1. Any directories specified with the /INCLUDE_DIRECTORY qualifier.
2. The directory or search list of directories specified in the logical name DECC$SYSTEM_INCLUDE, if DECC$SYSTEM_INCLUDE is defined.
3. If DECC$SYSTEM_INCLUDE is not defined, then the directory or search list of directories specified by DECC$LIBRARY_INCLUDE.
4. If neither DECC$SYSTEM_INCLUDE nor DECC$LIBRARY_INCLUDE are defined as logical names, the compiler searches the following directories for plain text-file copies of compiler header files:
   • SYS$COMMON:[DECC$LIB.INCLUDE.DECC$RTLDEF]
   • SYS$COMMON:[DECC$LIB.INCLUDE.SYS$STARLET_C]
   
   Normally, the compiler installation does not put any files in these directories, but the compiler will search them if they exist.
5. If the file is still not found, all directories and the file extension are stripped off and the steps for including a module from a text library are followed.
6. If the file is still not found, SYS$LIBRARY is searched.

You can define DECC$SYSTEM_INCLUDE to be a valid directory specification or a search list of valid directory specifications. Before each compilation of your program, you can redefine DECC$SYSTEM_INCLUDE to be any valid directory or list of directories you choose.

Avoid defining DECC$SYSTEM_INCLUDE to be a rooted directory or subdirectory of the following form:

DBA0:[dir-name.]

When defining DECC$SYSTEM_INCLUDE, use complete directory specifications.

If DECC$SYSTEM_INCLUDE translates to a directory or a search list of directories, and if the compiler cannot locate the specified file, the compiler generates an error message. If DECC$SYSTEM_INCLUDE is undefined, the compiler then searches the DECC$LIBRARY_INCLUDE or SYS$LIBRARY directory for the specified file; if the file cannot be found, the compiler generates an error message. For more information about search lists, see the DCL command DEFINE in the HP OpenVMS DCL Dictionary.

When porting programs to the OpenVMS environment, your programs may contain #include directives of the following form:

#include <sys/file.h>

The HP C compiler translates this line, common in programs that run on UNIX systems, to the following UNIX style file specification:

/sys/file.h

The compiler then translates the UNIX style file specification to the OpenVMS file specification as follows:

SYS:FILE.H

If you port programs containing such directives, define the SYS logical to be the proper name of the OpenVMS directory containing the files to be included.

Another way to use UNIX style directories is to specify them on the /INCLUDE_DIRECTORY command-line qualifier. They must contain a "/" character and must, therefore, be in quotation marks.