United States |
|
|
||
5.4.1.2 #pragma assert global_status_variable (ALPHA ONLY)Use this form of the pragma to specify variables that are to be considered global status variables, which are exempt from any assertions given to functions by #pragma assert func_attrs file_scope_vars directives.
The variable-list is a list of variables.
The following notes apply to the #pragma assert func_attrs and #pragma assert global_status_variable forms of the #pragma assert directive:
5.4.1.4 #pragma assert non_zeroThis form of the #pragma assert directive is supported on both VAX and Alpha platforms. When the compiler encounters this directive, it evaluates the constant-expression. If the expression is zero, the compiler generates a message that contains both the specified string-literal and the compile-time constant-expression. For example:
In this example, if the compiler determines that sizeof a is not 12, the following diagnostic message is output:
Unlike the #pragma assert options func_attrs and global_status_variable , #pragma assert non_zero can appear either inside or outside a function body. When used inside a function body, the pragma can appear wherever a statement can appear, but the pragma is not treated as a statement. When used outside a function body, the pragma can appear anywhere a declaration can appear, but the pragma is not treated as a declaration. Because macro replacement is not performed on #pragma assert , you might need to use the #pragma assert_m directive to obtain the results you want. Consider the following program that verifies both the size of a struct and the offset of one of its elements:
Because
offsetof
is a macro, the second pragma must be
#pragma assert_m
so that
offsetof
will expand correctly.
The #pragma builtins directive enables the Compaq C built-in functions that directly access processor instructions. This directive is provided for VAX C compatibility. The #pragma builtins directive has the following format:
Compaq C implements #pragma builtins by including the <builtins.h> header file, and is equivalent to #include <builtins.h> on OpenVMS systems. This header file contains prototype declarations for the built-in functions that allow them to be used properly. By contrast, VAX C implemented this pragma with special-case code within the compiler, which also supported a #pragma nobuiltins preprocessor directive to turn off the special processing. Because declarations cannot be "undeclared", Compaq C does not support #pragma nobuiltins . Furthermore, the names of all the built-in functions use a naming convention defined by ANSI C to be in a namespace reserved to the C language implementation. (For more details, see the following Note.)
5.4.3 #pragma dictionary DirectiveThe #pragma dictionary directive allows you to extract CDD/Repository data definitions and include these definitions in your program. The ANSI C compliant #pragma dictionary directive is equivalent to the VAX C compatible #dictionary directive ( Section 5.1), but is supported in all compiler modes. (The #dictionary directive is retained for compatibility and is supported only when compiling with the /STANDARD=VAXC qualifier.) The #pragma dictionary directive has the following format:
The CDD_path is a character string that gives the path name of a CDD/Repository record, or a macro that expands to the path name of the record. The optional null_terminate keyword can be used to specify that all string data types should be null-terminated. The optional name() can be used to supply an alternate tag name or declarator(struct_name) for the outer level of a CDD/Repository structure. The optional text1_to_char keyword forces the CDD/Repository type "text" to be translated to char , rather than "array of char " if the size is 1. This is the default when null_terminate is not specified. The optional text1_to_array keyword forces the CDD/Repository type "text" to be translated to type "array of char " even when the size is 1. This is the default when null_terminate is specified. Here's a sample #pragma dictionary directive:
This path name describes all subdirectories, beginning with the root directory (CDD$TOP), that lead to the salary_record data definition. You can use the logical name CDD$DEFAULT to define a default path name for a dictionary directory. This logical name can specify part of the path name for the dictionary object. For example, you can define CDD$DEFAULT as follows:
When this definition is in effect, the #pragma dictionary directive can contain the following:
Descriptions of data definitions are entered into the dictionary in a special-purpose language called CDO (Common Dictionary Operator), which replaces the older interface called CDDL (Common Data Dictionary Language). CDD definitions written in CDDL are included in a dictionary with the CDDL command. For example, you can write the following definition for a structure containing someone's first and last name:
If a source file named CNAME.DDL needs to use this definition, you can include the definition in the CDD subdirectory named doc by entering the following command:
After executing this command, a Compaq C program can reference this definition with the #pragma dictionary directive. If the #pragma dictionary directive is not embedded in a Compaq C structure declaration, then the resulting structure is declared with a tag name corresponding to the name of the CDD/Repository record. Consider the following example:
This Compaq C preprocessor statement results in the following declarations:
You can also embed the #pragma dictionary directive in another Compaq C structure declaration as follows:
These lines of code result in the following declaration, which uses cname as an identifier for the embedded structure:
If you specify /LIST and either /SHOW=DICTIONARY or /SHOW=ALL in the compilation command line, then the translation of the CDD/Repository record description into Compaq C is included in the listing file and marked with the letter D in the margin.
For information on Compaq C support for CDD/Repository data types.
see Section C.4.3.
The #pragma environment directive offers a global way to set, save, or restore the states of context pragmas. This directive protects include files from contexts set by encompassing programs, and protects encompassing programs from contexts that could be set in header files that they include. The #pragma environment directive affects the following context pragmas: #pragma extern_model This pragma has the following syntax:
The command_line keyword sets the states of all the context pragmas as specified on the command line (by default or by explicit use of the /[NO]MEMBER_ALIGNMENT, /[NO]WARNINGS, /EXTERN_MODEL, and /POINTER_SIZE qualifiers). You can use #pragma environment command_line within header files to protect them from any context pragmas that take effect before the header file is included. The header_defaults keyword sets the states of all the context pragmas to their default values. This is almost equivalent to the situation in which a program with no command-line options and no pragmas is compiled, except that this pragma sets the pragma message state to #pragma nostandard , as is appropriate for header files. The save keyword saves the current state of every pragma that has an associated context. The restore keyword restores the current state of every pragma that has an associated context. Without requiring further changes to the source code, you can use #pragma environment to protect header files from things like language extensions and enhancements that might introduce additional contexts. A header file can selectively inherit the state of a pragma from the including file and then use additional pragmas as needed to set the compilation to non-default states. For example:
In this example:
Thus, the header file is protected from all pragmas, except for the
member alignment context that the header file was meant to inherit.
The #pragma extern_model directive controls how the compiler interprets objects that have external linkage. With this pragma, you can choose one of the following global symbol models to be used for external objects:
After a global symbol model is selected with the extern_model pragma, all subsequent declarations of objects having external storage class are treated according to the specified model until another extern_model pragma is specified. For example, consider the following pragma:
After this pragma is specified, the following file-level declarations are treated as declaring global symbols according to the strict ref/def model:
Regardless of the external model, the compiler uses ANSI C rules to determine if a declaration is a definition or a reference, although that distinction is not used in the common block model. An external definition is a file-level declaration that has no storage-class keyword, or that contains the extern storage-class keyword, and is also initialized. A reference is a declaration that uses the extern storage-class keyword and is not initialized. In the previous example, the declaration of x is a global definition and the declaration of y is a global reference. The extern_model pragma does not affect the processing of declarations that contain the VAX C keywords globaldef , globalref , or globalvalue . Compaq C also supports the command-line qualifiers /EXTERN_MODEL and /SHARE_GLOBALS to set the external model when the program starts to compile. Pragmas in the program being compiled supersede the command-line qualifier. A stack of the compiler's external model state is kept so that #pragma extern_model can be used transparently in header files and in small regions of program text. See Sections 5.4.5.6 and 5.4.5.7 for more information. The compiler issues an error message if the same object has two different external models specified in the same compilation unit, as in the following example:
See Section 5.4.5.8 to determine what combinations of external models are compatible for successfully compiling and linking your programs.
The following sections describe the various forms of the
#pragma extern_model
directive.
The #pragma extern_model directive has the following syntax:
model_spec is one of the following: common_block [attr[,attr]...] are optional psect attribute specifications chosen from the following (at most one from each line): gbl lcl (Not allowed with relaxed_refdef ) The last line of attributes are numeric alignment values. When a numeric alignment value is specified on a section, the section is given an alignment of two raised to that power. On OpenVMS Alpha systems, the strict_refdef "name" extern_model can also take the following psect attribute specifications:
See Table 4-3 for a description of the other attributes. See the OpenVMS Linker Utility Manual for more complete information on each. The default attributes are: noshr , rel , noexe , novec , nopic . For strict_refdef , the default is con . For common_block and relaxed_refdef , the default is ovr . The default for wrt / nowrt is determined by the first variable placed in the psect. If the variable has the const type qualifier (or the readonly modifier), the psect is set to nowrt . Otherwise, it is set to wrt .
Restrictions on Setting Psect Attributes
Be aware of the following restriction on setting psect attributes. The #pragma extern_model directive does not set psect attributes for variables declared as tentative definitions in the relaxed_refdef model . A tentative definition is one that does not contain an initializer. For example, consider the following code:
Psect A is given octaword alignment (the default) because a is a tentative definition. Psect B is correctly given longword alignment because it is initialized and is, therefore, not a tentative definition. Psect C is also given longword alignment because it is declared in an extern_model other than relaxed_refdef .
| |
privacy statement and legal notices |