Jump to 
content
HP.com Home Products and Services Support and Drivers Solutions How to Buy
»  Contact HP

 

dec_c_help.HLP

Null_directive (#)

A preprocessing directive of the form # <newline> is a null directive and has no effect.

Conditional_Compilation

Conditional compilation is provided by the following directives: #if constant-expression Checks whether the constant expression is nonzero (true). #ifdef identifier Checks whether the identifier is defined. #ifndef identifier Checks whether the identifier is undefined. #else Introduces source lines to be compiled as an alternative to the conditions tested by the previous directives. #elif constant-expression Delimits alternative source lines to be compiled if the constant expression in the corresponding #if, #ifdef, or #ifndef directive is false and if the additional constant expression presented in the #elif directive is true. An #elif directive is optional. #endif Ends the scope of the previous directives. If the condition checked by #if, #ifdef, or #ifndef is true, then all lines between the #else, #elif, and #endif are ignored. If the condition is false, then any lines between the conditional directive and the #else or #elif (if any) are ignored. If there is no #else, then the lines between the conditional and the #endif are ignored.

#define

The #define preprocessor directive has the form: #define identifier token-string The preprocessor substitutes the token string everywhere in the program that it finds the identifier except within comments, character constants, or string constants. Macro replacements are defined in a #define directive of the following form: #define name([parm1[,parm2,...]]) token-string Within the program, all macro references that have the following form are replaced by the token string. The arguments in the macro reference replace the corresponding parameters in the token string. name([arg1[,arg2,...]])

#dictionary

The #dictionary directive is retained for compatibility with VAX C and is supported only when running the HP C compiler in VAX C mode (/STANDARD=VAXC). See also the ANSI C equivalent #pragma dictionary directive. The #dictionary directive extracts Common Data Dictionary (CDD) definitions from the specified dictionary. These definitions are then translated into HP C and included in the program. The #dictionary directive has the following form: #dictionary "cdd_path" The cdd_path is a character string that gives the path name of the CDD record. It can also be a macro that resolves to such a character string.

#error

The #error directive issues an optional diagnostic message, and ends compilation. This directive has the following form: #error [message] <newline>

#include

The #include directive instructs the preprocessor to insert the contents of the specified file or module into the program. An #include directive can have one of three forms: #include "filespec" #include <filespec> #include module-name The first two forms are ANSI-compliant methods of file inclusion and are therefore more portable. In these forms, .h is the default file type, unless the compiler is instructed to supply no default type (that is, a type of just ".") by the /ASSUME=NOHEADER_TYPE_DEFAULT qualifier. The third form is specific to OpenVMS systems for specifying the inclusion of a module from a text library, and is not generally needed or recommended because the ANSI forms also cause the text libraries to be searched. For the order of search, see /INCLUDE_DIRECTORY. There is no defined limit to the nesting level of #include files and modules.

#line

The #line directive applies a specified line number and optional file specification to the next line of source text. This can be useful for diagnostic messages. The #line directive has the following forms: #line integer-constant <newline> #line integer-constant "filename" <newline> #line pp-tokens <newline> In the first two forms, the compiler gives the line following a #line directive the number specified by the integer constant. The optional filename in quotation marks indicates the name of the source file that the compiler will provide in its diagnostic messages. If the filename is omitted, the file name used is the name of the current source file or the last filename specified in a previous #line directive. In the third form, macros in the #line directive are expanded before it is interpreted. This allows a macro call to expand into the integer-constant, filename, or both. The resulting #line directive must match one of the other two forms, and is then processed as appropriate.

#module

The #module directive is retained for compatibility with VAX C and is supported only when running the HP C compiler in VAX C mode (/STANDARD=VAXC). See also the ANSI C equivalent #pragma module directive. The #module directive passes information about an object module to the compiler. The #module directive can have one of the following forms: #module identifier identifier #module identifier string The first argument of the directive is an HP C identifier or macro that resolves to an identifier. It gives the system-recognized (for example, internally recognized by the debugger and the librarian) name of the module; the object file name remains the same. The second argument specifies the optional identification that appears on listings. This may be either a VAX C identifier, a character-string constant with no more than 31 characters, or a macro that resolves to one of these. There can be only one #module directive per compilation. It can appear anywhere before the C language text.

#pragma

The #pragma preprocessor directive performs compiler-specific tasks as designated by each implementation of the C language. All pragmas have a <pragma-name>_m version, which makes the pragma subject to macro replacement. For example, #pragma assert is not subject to macro expansion, but #pragma assert_m is. All pragmas also have a <pragma-name>_nm version, which prevents macro expansion. For example, #pragma inline is subject to macro expansion, but #pragma inline_nm is not. There is also a _Pragma operator (C99 Standard), which destringizes its string literal argument, effectively allowing #pragma directives to be produced by macro expansion. When specified using this operator, the tokens of the pragma, which appear together within a single string literal in this form, are not macro expanded, even if they have an "_m" suffix. But macro expansion can be accomplished if desired by using the stringization operator (#) to form the string. The _Pragma operator has the following syntax: _Pragma ( string-literal ) HP C for OpenVMS Systems supports the following #pragma directives: #pragma assert[_m|_nm] Lets you specify assertions that the compiler can make about a program to generate more efficient code. The #pragma assert directive is never needed to make a program execute correctly, however if a #pragma assert is specified, the assertions must be valid or the program might behave incorrectly. Syntax: #pragma assert func_attrs(identifier-list)function-assertions #pragma assert global_status_variable(variable-list) #pragma assert non_zero(constant-expression) string-literal Descriptions follow. The #pragma assert func_attrs directive: The identifier-list is a list of function identifiers about which the compiler can make assertions. If more than one identifier is specified, separate them by commas. The function-assertions specify the assertions for the compiler to make about the functions. Specify one or more of the following, separating multiple assertions with whitespace: noreturn The compiler can assert that any call to the routine will never return. nocalls_back The compiler can assert that no routine in the source module will be called before control is returned from this function. nostate The compiler can assert that the value returned by the function and any side-effects the function might have are determined only by the function's arguments. If a function is marked as having both noeffects and nostate, the compiler can eliminate redundant calls to the function. noeffects The compiler can assert that any call to this function will have no effect except to set the return value of the function. If the compiler determines that the return value from a function call is never used, it can remove the call. file_scope_vars(option) The compiler can make assertions about how a function will access variables declared at file scope (with either internal or external linkage). The file_scope_vars option is one of the following: o none - The function will not read nor write to any file-scope variables except those whose type is volatile or those listed in a #pragma assert global_status_variable. o noreads - The function will not read any file-scope variables except those whose type is volatile or those listed in a #pragma assert global_status_variable. o nowrites - The function will not write to any file-scope variables except those whose type is volatile or those listed in a #pragma assert global_status_variable. format (<style>, <format-index>, <first-to-check-index>) Asserts to the compiler that this function takes printf- or scanf-style arguments to be type-checked against a format string. Specify the parameters as follows: o <style> -- PRINTF or SCANF. This determines how the format string is interpreted. o <format-index> -- {1|2|3|...} This specifies which argument is the format-string argument (starting from 1). o <first-to-check-index> -- {0|1|2|...} This is the number of the first argument to check against the format string. For functions where the arguments are not available to be checked (such as vprintf), specify the third parameter as 0. In this case, the compiler only checks the format string for consistency. The #pragma assert global_status_variable directive: Use the #pragma assert global_status_variable(variable-list) 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 #pragma assert non_zero directive: 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: #pragma assert non_zero(sizeof(a) == 12) "a is the wrong size" In this example, if the compiler determines that the sizeof a is not 12, the following diagnostic message is output: CC-W-ASSERTFAIL, The assertion "(sizeof(a) == 12)" was not true. a is the wrong size. 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: #include <stddef.h> typedef struct { int a; int b; } s; #pragma assert non_zero(sizeof(s) == 8) "sizeof assert failed" #pragma assert_m non_zero(offsetof(s,b) == 4) "offsetof assert failed" Because offsetof is a macro, the second pragma must be #pragma assert_m so that offsetof will expand correctly. #pragma builtins[_m|_nm] Enables the HP C built-in functions that directly access processor instructions. The #pragma builtins directive is provided for VAX C compatibility. HP 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", HP 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. #pragma dictionary[_m|_nm] Allows you to extract CDD 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, 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.) Syntax: #pragma dictionary "cdd_path" [null_terminate] [name(structure_name)] [text1_to_array | text1_to_char] The cdd_path is a character string that gives the path name of the CDD record. It can also be a macro that resolves to such a character string. 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 a declarator, struct_name for the outer level of a CDD structure. The optional text1_to_char keyword forces the CDD type "text" to be translated to char, rather than "array of char" if the size is 1. This is the default if null_terminate is not specified. The optional text1_to_array keyword forces the CDD 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. #pragma environment[_m|_nm] Sets, saves, or restores 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 pragmas: o #pragma extern_model o #pragma extern_prefix o #pragma member_alignment o #pragma message o #pragma names o #pragma pointer_size o #pragma required_pointer_size Syntax: #pragma environment command_line #pragma environment header_defaults #pragma environment restore #pragma environment save command_line Sets, as specified on the command line, the states of all the context pragmas. You can use this pragma to protect header files from environment pragmas that take effect before the header file is included. header_defaults 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. save Saves the current state of every pragma that has an associated context. restore Restores the current state of every pragma that has an associated context. #pragma extern_model[_m|_nm] Controls the compiler's interpretation of objects that have external linkage. This pragma lets you choose the global symbol model to be used for externs. Syntax: #pragma extern_model common_block [attr[,attr]...] #pragma extern_model relaxed_refdef [attr[,attr]...] #pragma extern_model strict_refdef "name" [attr[,attr]...] #pragma extern_model strict_refdef #pragma extern_model globalvalue #pragma extern_model save #pragma extern_model restore The default model on HP C is #pragma relaxed_refdef noshr. This is different from the model used by VAX C, which is common block, shr. The [attr[,attr]...] are optional psect attribute specifications chosen from the following (at most one from each line): o gbl lcl (Not allowed with relaxed_refdef) o shr noshr o wrt nowrt o pic nopic (Not meaningful for Alpha) o ovr con o rel abs o exe noexe o vec novec o noreorder (named strict_refdef only) o natalgn (named strict_refdef only) o 0 byte 1 word 2 long 3 quad 4 octa 5 6 7 8 9 10 11 12 13 14 15 16 page See the HP C User's Guide for more information on the #pragma extern_model directive. #pragma extern_prefix[_m|_nm] Controls the compiler's synthesis of external names, which the linker uses to resolve external name requests. When you specify #pragma extern_prefix with a string argument, the compiler prepends the string to all external names produced by the declarations that follow the pragma specification. This pragma is useful for creating libraries where the facility code can be attached to the external names in the library. Syntax: #pragma extern_prefix "string" [(id[,id]...)] #pragma extern_prefix {NOCRTL|RESTORE_CRTL} (id[,id]...) #pragma extern_prefix save #pragma extern_prefix restore Where "string" prepends the quoted string to external names in the declarations that follow the pragma specification. You can also specify an extern prefix for specific identifiers using the optional list [(<emphasis>(id)[,<emphasis>(id)]...)]. The NOCRTL and RESTORE_CRTL keywords control whether or not the compiler applies its default RTL prefixing to the names specified in the id-list, required for this form of the pragma. The effect of NOCRTL is like that of the EXCEPT=keyword of the /PREFIX_LIBRARY_ENTRIES command-line qualifier. The effect of RESTORE_CRTL is to undo the effect of a #pragma extern_prefix NOCRTL or a /PREFIX=EXCEPT= on the command line. The save and restore keywords can be used to save the current pragma prefix string and to restore the previously saved pragma prefix string, respectively. The default external prefix, when none has been specified by a pragma, is the null string. #pragma function[_m|_nm] Specifies that calls to the specified functions are not intrinsic but are, in fact, function calls. This pragma has the opposite effect of #pragma intrinsic. Syntax: #pragma function[_m|_nm] (function1[, function2, ...]) #pragma include_directory[_m|_nm] The effect of each #pragma include_directory is as if its string argument (including the quotes) were appended to the list of places to search that is given its initial value by the /INCLUDE_DIRECTORY qualifier, except that an empty string is not permitted in the pragma form. Syntax: #pragma include_directory <string-literal> This pragma is intended to ease DCL command-line length limitations when porting applications from POSIX-like environments built with makefiles containing long lists of -I options specifying directories to search for headers. Just as long lists of macro definitions specified by the /DEFINE qualifier can be converted to #define directives in a source file, long lists of places to search specified by the /INCLUDE_DIRECTORY qualifier can be converted to #pragma include_directory directives in a source file. Note that the places to search, as described in the help text for the /INCLUDE_DIRECTORY qualifier, include the use of POSIX-style pathnames, for example "/usr/base". This form can be very useful when compiling code that contains POSIX-style relative pathnames in #include directives. For example, #include <subdir/foo.h> can be combined with a place to search such as "/usr/base" to form "/usr/base/subdir/foo.h", which will be translated to the filespec "USR:[BASE.SUBDIR]FOO.H" This pragma can appear only in the main source file or in the first file specified on the /FIRST_INCLUDE qualifier. Also, it must appear before any #include directives. #pragma [no]inline[_m|_nm] Expands function calls inline. The function call is replaced with the function code itself. Syntax: #pragma inline (id,...) #pragma noinline (id,...) If a function is named in an inline directive, calls to that function will be expanded as inline code, if possible. If a function is named in a noinline directive, calls to that function will not be expanded as inline code. If a function is named in both an inline and a noinline directive, an error message is issued. For calls to functions named in neither an inline nor a noinline directive, DEC C expands the function as inline code whenever appropriate as determined by a platform-specific algorithm. #pragma intrinsic[_m|_nm] Specifies that calls to the specified functions are intrinsic (that is, handled internally by the compiler, allowing it to generate inline code, move or eliminate calls, or do various other optimizations). This pragma is only valid for functions that are known to the compiler. Syntax: #pragma intrinsic (function1[, function2, ...]) #pragma linkage[_m|_nm] Specifies special linkage types for function calls. This pragma is used with the #pragma use_linkage directive, which associates a previously defined special linkage with a function. Syntax: #pragma linkage linkage-name = (characteristics) #pragma linkage_ia64 linkage-name = (characteristics) On I64 systems, these two formats behave differently: o The #pragma linkage_ia64 format requires I64 register names be specified. o The #pragma linkage format requires Alpha register names be specified, which are automatically mapped, where possible, to specific I64 registers. The two formats are further described after the description of the characteristics. The characteristics specify information about where parameters will be passed, where the results of the function are to be received, and what registers are modified by the function call. Specify these characteristics as a parenthesized list of items of the following forms: parameters (register-list) result (simple-register-list) preserved (simple-register-list) nopreserve (simple-register-list) notused (simple-register-list) notneeded (ai, lp) standard_linkage You can supply the option keywords in any order. Description of Options: simple-register-list A comma-separated list of register names, either Rn or Fn. Example: nopreserve(F5, F6) For the #pragma linkage format, valid registers for the preserved, nopreserve, and notused options include general-purpose registers R0 through R30, and floating-point registers F0 through F30. Valid registers for the result and parameters options include general-purpose registers R0 through R25, and floating-point registers F0 through F30. For the #pragma linkage_ia64 format, see below for an explanation of register usage. register-list Similar to a simple-register-list except that it can contain parenthesized sublists. Use the register-list to describe arguments and function result types that are structs, where each member of the struct is passed in a single register. Example: parameters(R5, (F5, F6)) parameters Use this option to pass arguments to the parameters of a routine in specific registers. result Use this option to specify the register to be used to return the value for the function. If a function has a return type of void, do not specify the result option as part of the linkage. preserved A preserved register contains the same value after a call to the function as it did before the call. nopreserve A nopreserve register does not necessarily contain the same value after a call to the function as it did before the call. notused A notused register is not used in any way by the called function. notneeded Indicates that certain items are not needed by the routines using this linkage. Valid options are: AI -- Specifies that the Argument Information register (R25) does not need to be set up when calling the specified functions. LP -- Specifies that the Linkage Pointer register does not need to be set up when calling the specified functions. Note that for I64 systems, there is no linkage pointer, so this setting is accepted but does not change the behavior of the pragma. standard_linkage Tells the compiler to use the standard linkage appropriate to the target platform. This can be useful to confine conditional compilation to the pragmas that define linkages, without requiring the corresponding #pragma use_linkage directives to be conditionally compiled as well. If the standard_linkage keyword is specified, it must be the only option in the parenthesized list following the linkage name. For example: #pragma linkage special1 = (standard_linkage) If the standard_linkage keyword is not specified, you can supply the parameters, result, preserved, nopreserve, and notused options in any order, separated by commas. Description of the two formats of this pragma: The #pragma linkage_ia64 format of this preprocessor directive requires register names to be specified in terms of an OpenVMS I64 system. The register names are never mapped to a different architecture. This form of the pragma always produces an error if encountered on a different architecture. For this format of the pragma, valid registers for the preserved, nopreserve, notused, parameters, and result options are: o Integer registers R3 through R12 and R19 through R31 o Floating-point registers F2 through F31 In addition, the parameters and result options also permit integer registers R32 through R39 to be specified, according to the following convention. On IA64, the first eight integer input/output slots are allocated to stacked registers, and thus the calling routine refers to them using different names than the called routine. The convention for naming these registers in either the parameters or result option of a #pragma linkage_ia64 directive is always to use the hardware names as they would be used within the called routine: R32 through R39. The compiler automatically compensates for the fact that within the calling routine these same registers are designated using different hardware names. The #pragma linkage format of this preprocessor directive accepts Alpha register names and conventions and automatically maps them, where possible, to specific I64 registers. So whenever HP C for I64 encounters a #pragma linkage directive, it attempts to map the Alpha registers specified in the linkage to corresponding I64 registers, and emits a SHOWMAPLINKAGE informational message showing the I64 specific form of the directive, #pragma linkage_ia64, with the I64 register names that replaced the Alpha register names. The SHOWMAPLINKAGE message is suppressed under the #pragma nostandard directive, normally used within system header files. Code compiled on I64 systems that deliberately relies on the register mapping performed by #pragma linkage should either ignore the SHOWMAPLINKAGE informational, or disable it. The following shows the mapping that HP C applies to the Alpha integer register names used in #pragma linkage format directives when they are encountered on an I64 system. Note that the six standard parameter registers on Alpha (R16-R21) are mapped to the first six (of eight) standard parameter registers on I64 systems, which happen to be stacked registers: Integer Register Mapping: Alpha -> I64 Alpha -> I64 R0 -> R8 R16 -> R32 * R1 -> R9 R17 -> R33 * R2 -> R28 R18 -> R34 * R3 -> R3 R19 -> R35 * R4 -> R4 R20 -> R36 * R5 -> R5 R21 -> R37 * R6 -> R6 R22 -> R22 R7 -> R7 R23 -> R23 R8 -> R26 R24 -> R24 R9 -> R27 R25 -> R25 R10 ->R10 R26 - no mapping R11 ->R11 R27 - no mapping R12 ->R30 R28 - no mapping R13 ->R31 R29 -> R29 R14 ->R20 R30 -> R12 R15 ->R21 R31 -> R0 * In parameters or result; else ignored The following shows the mapping that HP C applies to the Alpha floating-point register names used in #pragma linkage directives when they are encountered on an I64 system: Floating-Point Register Mapping: Alpha -> I64 Alpha -> I64 F0 -> F8 F16 -> F8 F1 -> F9 F17 -> F9 F2 -> F2 F18 -> F10 F3 -> F3 F19 -> F11 F4 -> F4 F20 -> F12 F5 -> F5 F21 -> F13 F6 -> F16 F22 -> F22 F7 -> F17 F23 -> F23 F8 -> F18 F24 -> F24 F9 -> F19 F25 -> F25 F10 ->F6 F26 - F26 F11 ->F7 F27 - F27 F12 ->F20 F28 - F28 F13 ->F21 F29 -> F29 F14 ->F14 F30 -> F30 F15 ->F15 Mapping Diagnostics: In some cases, the HP C compiler on Alpha systems silently ignores linkage registers if, for example, a standard parameter register like R16 is specified in a preserved option. When you compile on an I64 system, this situation emits an MAPREGIGNORED informational message, and the SHOWMAPLINKAGE output might not be correct. If there is no valid mapping to I64 registers, the NOMAPPOSSIBLE error message is output. There are two special situations that can arise when floating-point registers are specified in a linkage: o Only IEEE-format values are passed in floating-point registers under the OpenVMS Calling Standard for I64: VAX format values are passed in integer registers. Therefore, a compilation that specifies /FLOAT=D_FLOAT or /FLOAT=G_FLOAT produces an error for any linkage that specifies floating-point registers. Note that this includes use in options that do not involve passing values, such as the preserved and notused options. o The mapping of floating-point registers is many-to-one in two cases: - Alpha registers F0 and F16 both map to I64 register F8 - Alpha F1 and F17 both map to I64 register F9. A valid Alpha linkage may well specify uses for both F0 and F16, and/or both F1 and F17. Such a linkage cannot be mapped on an I64 system. But because of the way this situation is detected, the MULTILINKREG warning message that is produced can only identify the second occurrence of an Alpha register that got mapped to the same I64 register as some previous Alpha register. The actual pair of Alpha registers in the source is not identified, and so the message can be confusing. For example, an option like preserved(F1,F17) gets a MULTILINKREG diagnostic saying that F17 was specified more than once. #pragma [no]member_alignment[_m|_nm] Tells the compiler to align structure members on the next boundary appropriate to the type of the member rather than the next byte. For example, a long variable is aligned on the next longword boundary; a short variable on the next word boundary. Syntax: #pragma nomember_alignment [base_alignment] #pragma member_alignment [save | restore] The optional base_alignment parameter can be used with #pragma nomember_alignment to specify the base alignment of the structure. Use one of the following keywords to specify the base_alignment: o BYTE (1 byte) o WORD (2 bytes) o LONGWORD (4 bytes) o QUADWORD (8 bytes) o OCTAWORD (16 bytes) The optional save and restore keywords can be used to save the current state of the member_alignment and to restore the previous state, respectively. This feature is necessary for writing header files that require member_alignment or nomember_alignment, or that require inclusion in a member_alignment that is already set. #pragma message[_m|_nm] Controls the issuance of individual diagnostic messages or groups of messages. Use of this pragma overrides any command-line options that may affect the issuance of messages. Syntax: #pragma message option1 message-list #pragma message option2 #pragma message (quoted-string) where option1 is: disable Suppresses the issuance of the indicated messages. Only messages of severity Warning (W) or Information (I) can be disabled. If the message has severity of Error (E) or Fatal (F), it is issued regardless of any attempt to disable it. enable Enables the issuance of the indicated messages. emit_once Emits the specified messages only once per compilation. emit_always Emits the specified messages at every occurrence of the condition. error Sets the severity of each message in the message-list to Error. fatal Sets the severity of each message on the message-list to Fatal. informational Sets the severity of each message in the message-list to Informational. warning Sets the severity of each message in the message-list to Warning. The message-list can be any one of the following: o A single message identifier (within parentheses or not). o A single message-group name (within parentheses or not). Message-group names are: ALL All the messages in the compiler ALIGNMENT Messages about unusual or inefficient data alignment. C_TO_CXX Messages reporting the use of C features that would be invalid or have a different meaning if compiled by a C++ compiler. CDD Messages about CDD (Common Data Dictionary) support. CHECK Messages reporting code or practices that, although correct and perhaps portable, are sometimes considered ill-advised because they can be confusing or fragile to maintain. For example, assignment as the test expression in an "if" statement. NOTE: The check group gets defined by enabling level5 messages. DEFUNCT Messages reporting the use of obsolete features: ones that were commonly accepted by early C compilers but were subsequently removed from the language. NEWC99 Messages reporting the use of the new C99 Standard features. NOANSI Messages reporting the use of non-ANSI Standard features. The NOANSI message group is a synonym for NOC89. Also see message groups NEWC99, NOC89, NOc99. NOC89 Messages reporting the use of non-C89 Standard features. NOC99 Messages reporting the use of non-C99 Standard features. OBSOLESCENT Messages reporting the use of features that are valid in ANSI Standard C, but which were identified in the standard as being obsolescent and likely to be removed from the language in a future version of the standard. OVERFLOW Messages that report assignments and/or casts that can cause overflow or other loss of data significance. PERFORMANCE Messages reporting code that might result in poor run-time performance. PORTABLE Messages reporting the use of language extensions or other constructs that might not be portable to other compilers or platforms. PREPROCESSOR Messages reporting questionable or non-portable use of preprocessing constructs. QUESTCODE Messages reporting questionable coding practices. Similar to the check group, but messages in this group are more likely to indicate a programming error rather than just a non-robust style. Enabling the QUESTCODE group provides lint-like checking. RETURNCHECKS Messages related to function return values. UNINIT Messages related to using uninitialized variables. UNUSED Messages reporting expressions, declarations, header files, CDD records, static functions, and code paths that are not used. Note, however, that unlike any other messages, these messages must be enabled on the command line (/WARNINGS=ENABLE=UNUSED) to be effective. o A single message-level name (within parentheses or not). Note: There is a core of very important compiler messages that are enabled by default, regardless of anything specified with /WARNINGS or #pragma message. Referred to as message level 0, it includes all messages issued in header files, and comprises what is known as the nostandard group. All other message levels add additional messages to this core of enabled messages. You cannot disable level 0. However, you can disable individual messages in level 0 that are not errors or fatals. Message-level names are: LEVEL1 Important messages. These are less important than level 0, because messages in this group are not displayed if #pragma nostandard is active. LEVEL2 Moderately important messages. This level is used to introduce new messages that will be output in the DIGITAL UNIX V4.0 release. LEVEL2 is the default for DIGITAL UNIX and Tru64 UNIX platforms. LEVEL3 Less important messages. In general, these are the messages output by default in DEC C Version 5.5 for OpenVMS Systems. LEVEL3 is the default message level for HP C for OpenVMS systems. LEVEL4 Useful check/portable messages. LEVEL5 Not so useful check/portable messages. LEVEL6 All messages in LEVEL5 plus additional "noisy" messages. Enabling a level also enables all the messages in the levels below it. So enabling LEVEL3 messages also enables messages in LEVEL2 and LEVEL1. Disabling a level also disables all the messages in the levels above it. So disabling LEVEL4 messages also disables messages in LEVEL5 and LEVEL6. o A comma-separated list of message identifiers, group names, and messages levels, freely mixed, enclosed in parentheses. option2 is: save -- saves the current state of which messages are enabled and disabled. restore -- restores the previous state of which messages are enabled and disabled. The save and restore options are useful primarily within header files. The #pragma message (quoted-string) form outputs the quoted-string as a compiler message. This form of the pragma is subject to macro replacement. For example, the following is valid: #pragma message ("Compiling file " __FILE__) #pragma module[_m|_nm] The ANSI C compliant #pragma module directive is equivalent to the VAX C compatible #module directive, but is supported in all compiler modes. (The #module directive is retained for compatibility and is supported only when compiling with the /STANDARD=VAXC qualifier.) The #pragma module directive is specific to HP C for OpenVMS Systems and is not portable. Use the #pragma module directive to change the system-recognized module name and version number. You can find the module name and version number in the compiler listing file and the linker load map. Syntax: #pragma module identifier identifier #pragma module identifier string The first parameter must be a valid HP C identifier. It specifies the module name to be used by the linker. The second parameter specifies the optional identification that appears on listings and in the object file. It must be either a valid HP C identifier of 31 characters or less, or a character-string constant of 31 characters or less. Only one #pragma module directive can be processed per compilation unit, and that directive must appear before any C language text. The #pragma module directive can follow other directives, such as #define, but it must precede any function definitions or external data definitions. #pragma names[_m|_nm] Provides the same kinds of control over the mapping of external identifiers' object-module symbols as does the /NAMES command-line qualifier, and it uses the same keywords. But as a pragma, the controls can be applied selectively to regions of declarations. This pragma should only be used in header files and is intended for use by developers who supply libraries and/or header files to their customers. The pragma has a save/restore stack that is also managed by #pragma environment, and so it is well-suited for use in header files. The effect of #pragma environment header_defaults is to set NAMES to "uppercase,truncated", which is the compiler default. Syntax: #pragma names <stack-option> #pragma names <case-option> #pragma names <length-option> Where <stack-option> is one of: o save - save the current names state o restore - restore a saved names state <case-option> is one of: o uppercase - uppercase external names o as_is - do not change case <length-option> is one of: o truncated - truncate at 31 characters o shortened - shorten to 31 using CRC #pragma optimize[_m|_nm] Sets the optimization characteristics of function definitions that follow the directive. It allows optimization-control options that are normally set on the command line for the entire compilation to be specified in the source file for individual functions. Syntax: #pragma optimize <settings> #pragma optimize save #pragma optimize restore #pragma optimize command_line Where <settings> is any combination of the following: o <level settings> Set the optimization level. Specify as: level=n Where n is an integer from 0 to 5. o <unroll settings> Control loop unrolling. Specify as: unroll=n Where n is a nonnegative integer. o <ansi-alias settings> Control ansi-alias assumptions. Specify one of the following: ansi_alias=on ansi_alias=off o <intrinsic settings> Control recognition of intrinsics. Specify one of the following: intrinsics=on intrinsics=off Use the save, restore, and command_line keywords as follows: o save -- Saves the current pointer size o restore -- Restores the current pointer size to its last saved state o command_line -- Sets the optimization settings to what was specified on the command line Example: #pragma optimize level=5 unroll=6 Usage Notes: o If the level=0 clause is present, it must be the only clause present. o The #pragma optimize directive must appear at file scope, outside any function body. o The #pragma environment save and restore operations include the optimization state. o The #pragma environment command_line directive resets the optimization state to that specified on the command line. o If #pragma optimize does not specify a setting for one of the optimization states, that state remains unchanged. o When a function definition is encountered, it is compiled using the optimization settings that are current at that point in the source. o When a function is compiled under level=0, the compiler will not inline that function. In general, when functions are inlined, the inlined code is optimized using the optimization controls in effect at the call site instead of using the optimization controls specified for the function being inlined. o When the OpenVMS command line specifies /NOOPT (or /OPTIMIZE=LEVEL=0), the #pragma optimize directive has no effect (except that its arguments are still validated). #pragma pack[_m|_nm] Specifies the byte boundary for packing members of C structures. Syntax: #pragma pack [n] The n specifies the new alignment restriction in bytes: 1 - align to byte 2 - align to word 4 - align to longword 8 - align to quadword 16 - align to octaword A structure member is aligned to either the alignment specified by #pragma pack or the alignment determined by the size of the structure member, whichever is smaller. For example, a short variable in a structure gets byte-aligned if #pragma pack 1 is specified. If #pragma pack 2, 4, or 8 is specified, the short variable in the structure gets aligned to word. When #pragma pack is specified without a value or with a value of 0, packing reverts to that specified by the /[NO]MEMBER_ALIGNMENT qualifier setting (either explicitly specified or by default) on the command line. Note that when specifying #pragma pack without a value, you must use parentheses: #pragma pack (). #pragma pointer_size[_m|_nm] Controls whether pointers are 32-bit pointers or 64-bit pointers. Syntax: #pragma pointer_size keyword Where keyword is one of the following: o short -- 32-bit pointer o long -- 64-bit pointer o system_default -- 32-bit pointers on OpenVMS systems; 64-bit pointers on Tru64 UNIX systems o save -- Saves the current pointer size o restore -- Restores the current pointer size to its last saved state This directive is enabled only when the /POINTER_SIZE command-line qualifier is specified. Otherwise, #pragma pointer_size has the same effect as #pragma required_pointer_size. #pragma required_pointer_size[_m|_nm] Intended for use by developers of header files to control pointer size within header files. Syntax: #pragma required_pointer_size keyword Where keyword is one of the following: o short -- 32-bit pointer o long -- 64-bit pointer o system_default -- 32-bit pointers on OpenVMS systems; 64-bit pointers on Tru64 UNIX systems o save -- Saves the current pointer size o restore -- Restores the current pointer size to its last saved state This directive is always enabled, even if the /POINTER_SIZE command-line qualifier is omitted. Otherwise, #pragma required_pointer_size has the same effect as #pragma pointer_size. #pragma [no]standard[_m|_nm] Directs the compiler to define regions of source code where portability diagnostics are not to be issued. Use #pragma nostandard to suppress diagnostics about non-ANSI C extensions, regardless of the /STANDARD qualifier specified, until a #pragma standard directive is encountered. Use #pragma standard to reinstate the setting of the /STANDARD qualifier that was in effect before before the last #pragma nostandard was encountered. Every #pragma standard directive must be preceded by a corresponding #pragma nostandard directive. Note that this pragma does not change the current mode of the compiler or enable any extensions not already supported in that mode. #pragma unroll[_m|_nm] Directs the compiler to unroll the for loop that follows it by the number of times specified in the unroll_factor argument. The #pragma unroll directive must be followed by a for statement. Syntax: #pragma unroll (unroll_factor) The unroll_factor is an integer constant in the range 0 to 255. If a value of 0 is specified, the compiler ignores the directive and determines the number of times to unroll the loop in its normal way. A value of 1 prevents the loop from being unrolled. The directive applies only to the for loop that follows it, not to any subsequent for loops. #pragma use_linkage[_m|_nm] Associates a special linkage, defined by the #pragma linkage directive, with the specified functions. Syntax: #pragma use_linkage linkage-name (routine1, routine2, ...) The linkage-name is the name of a linkage previously defined by the #pragma linkage directive. The parenthesized list contains the names of functions you want to associated with the named linkage. The list can also contain typedef names of function type, in which case functions or pointers to functions declared using that type will have the specified linkage.

#undef

The #undef directive cancels a previously defined macro replacement. Any other macro replacements that occurred before the #undef directive remain. The #undef directive has the following syntax: #undef identifier

Privacy statement Using this site means you accept its terms
© 2007 Hewlett-Packard Development Company, L.P.