HP OpenVMS Systems

1.3.1.2 Listing Header Files

To list the names of system header files, use the following commands:

$ LIBRARY/LIST SYS$LIBRARY:SYS$STARLET_C.TLB
(OpenVMS Version 7.1 and higher)
 
$ LIBRARY/LIST SYS$LIBRARY:DECC$RTLDEF.TLB
 
$ DIR SYS$COMMON:[DECC$LIB.REFERENCE.SYS$STARLET_C]*.H;
 
$ DIR SYS$COMMON:[DECC$LIB.REFERENCE.DECC$RTLDEF]*.H;
 
$ DIR SYS$LIBRARY:*.H; 

These commands list, respectively:

• The names of the text-module header files for the OpenVMS system interfaces
• The names of the text-module header files for the HP C language interfaces
• *.h header files for the OpenVMS system interfaces
• *.h header files for the HP C language interfaces
• *.h header files for layered products and other applications

Be aware that OpenVMS VAX operating systems prior to Version 7.1 do not have a file named SYS$LIBRARY:SYS$STARLET_C.TLB. For these older versions of the operating system, the STARLET header files are generated during HP C installation and placed in SYS$LIBRARY:DECC$RTLDEF.TLB and also in both SYS$COMMON:[DECC$LIB.REFERENCE.DECC$RTLDEF] and SYS$COMMON:[DECC$LIB.REFERENCE.SYS$STARLET_C].

1.3.2 Compilation Modes

HP C has two complementary qualifiers that control which dialect of C is to be recognized by the compiler, and which messages are generated:

• The /STANDARD qualifier controls what language features and extensions are recognized by the compiler.
• The /[NO]WARNINGS qualifier enables or disables the generation of warning and/or informational messages.

The /STANDARD qualifier causes the compiler to issue only those warnings appropriate for the dialect of C being compiled. For example, VAX C compatibility mode (/STANDARD=VAXC) does not issue warnings against VAX C extensions, while ANSI C mode does.

To generate a list of all messages that are in effect at the start of compilation, specify /LIST/SHOW=MESSAGES. For each message, the identifier, severity, and message text are shown. To also show the message description and user action for each message listed, specify /LIST/SHOW=MESSAGES/WARN=VERBOSE.

The HP C compiler for OpenVMS systems provides several dialects of C, which are controlled by the /STANDARD qualifier:

• Strict ANSI C: Only the ANSI C Standard 89 (C89) language dialect is recognized. This mode is enabled by specifying /STANDARD=ANSI89 on the CC command line.
  /STANDARD=ANSI89 issues all diagnostics required by the ANSI C standard as well as a number of optional diagnostics that help detect source code constructs that are not portable under the C89 standard. Digraph recognition from the 1994 Amendment is also supported in this mode.
  You can use /STANDARD=ANSI89 with /[NO]WARNINGS to control issuance of informational or warning messages. However, since the compiler does not recognize many VAX C or common C extensions when in strict ANSI mode (for example, VAX C keywords not beginning with two underscores), many of the messages normally associated with flagging VAX C and common C extensions are not produced.
• Strict C99 : Only the ISO C99 dialect is recognized. This mode is enabled by specifying /STANDARD=C99 on the CC command line.
  /STANDARD=C99 accepts just the C99 language without extensions, and diagnoses violations of the C99 standard. /STANDARD=C99 defines the __STDC_VERSION__ macro to the C99-specified value of 199901L, because C99 is a superset of Amendment 1 to the C89 standard, and the default mode of RELAXED is a superset of C99.
  Only when the ISOC94 keyword is specified alone or with the ANSI89, MIA, RELAXED, MS, COMMON, or PORTABLE modes does the __STDC_VERSION__ macro take on the Amendment 1 value of 199409L.
  The __STDC_VERSION__ macro is undefined for the VAXC keyword or for keywords ANSI89, MIA, or COMMON without ISOC94 specified.
  /STANDARD=C99 also defines the __STDC_HOSTED__ macro to 1. This macro is defined only for /STANDARD=LATEST and /STANDARD=C99.

  Note /STANDARD=C99 is not fully supported on VAX systems. Specifying /STANDARD=C99 on OpenVMS VAX systems produces a warning and puts the compiler into /STANDARD=RELAXED mode.

• Latest C standard dialect . /STANDARD=LATEST is currently equivalent to /STANDARD=C99, but is subject to change when newer versions of the C standard are released.
• Relaxed: This is the default mode on OpenVMS systems, and is specified by /NOSTANDARD or /STANDARD=RELAXED on the CC command line. The /STANDARD=RELAXED mode accepts C89 and C99 features, as well as nearly all language extensions (such as additional HP C keywords and predefined macros that do not begin with an underscore). It excludes only K&R (COMMON mode), VAX C, and Microsoft features that conflict with standard C. The purpose of the /STANDARD=RELAXED mode is to support everything from the most current C standard, in addition to all extensions that do not specify different semantics for the same constructs.
  /STANDARD=RELAXED defines the __STDC_VERSION__ macro to the C99-specified value of 199901L.
• Microsoft compatibility: This mode interprets source programs according to certain language rules followed by the C compiler provided with the Microsoft Visual C++ compiler product. This mode is enabled by specifying /STANDARD=MS on the CC command line. /STANDARD=MS defines the __STDC_VERSION__ macro to the C99-specified value of 199901L. See Section 1.3.3 for more information about Microsoft compatibility mode.
• ISO C 94: This mode is enabled by specifying /STANDARD=ISOC94. It can be specified alone or with any other /STANDARD option except VAXC. If it is specified alone, the default major mode is RELAXED.
  Specifying /STANDARD=ISOC94 enables digraph processing. Also, as specified by Amendment 1 to the C89 standard, it defines the __STDC_VERSION__ macro to 199409L if specified alone or in combination with any of the following /STANDARD keywords: ANSI89, MIA, RELAXED, MS, COMMON, or PORTABLE.
  The __STDC_VERSION__ macro is undefined for the VAXC keyword or for keywords ANSI89, MIA, or COMMON without ISOC94 specified.
• VAX C compatibility: This mode is enabled by specifying /STANDARD=VAXC. It allows the same language as the C standard, but also supports VAX C extensions that are incompatible with the C standard and that change the language semantics. This mode provides compatibility for programs that depend on old VAX C behavior.
• Portable: This mode is enabled by specifying /STANDARD=PORTABLE. It places the compiler in RELAXED mode and enables the issuance of diagnostics that warn about any nonportable usages encountered.
  /STANDARD=PORTABLE is supported for VAX C compatibility only. It is equivalent to the recommended combination of qualifiers /STANDARD=RELAXED/WARNINGS=ENABLE=PORTABLE.
• Common usage C: This mode is enabled by specifying /STANDARD=COMMON. It enforces K & R programming style; that is, compatibility with older UNIX compilers such as pcc and gcc . This mode is close to a subset of /STANDARD=VAXC mode.
• MIA conformance: This mode is enabled by specifying /STANDARD=MIA. This is strict ANSI C with some differences required by the Multivendor Integration Architecture (MIA) standard. Compiling a program with /STANDARD=MIA sets the __MIA predefined macro to 1.

With one exception, the /STANDARD qualifier options are mutually exclusive. Do not combine them. The exception is that you can specify /STANDARD=ISOC94 with any other option except VAXC.

HP C modules compiled in different modes can be linked and executed together.

The /STANDARD qualifier is further described in Section 1.3.4.

Also see the __HIDE_FORBIDDEN_NAMES predefined macro ( Section 6.1.7).

1.3.3 Microsoft Compatibility Compilation Mode

The /STANDARD=MS qualifier instructs the HP C compiler to interpret your source code according to certain language rules followed by the C compiler provided with the Microsoft Visual C++ compiler product. However, compatibility with this implementation is not complete. The following sections describe the compatibility situations that HP C recognizes. In most cases, these situations consist of relaxing a standard behavior and suppressing a diagnostic message.

1.3.3.1 Unnamed Nested struct or union Members

Allow a declaration of a structure with no name within another structure. You can reference all members of the inner structure as members of the named outer structure. This is similar to the C++ treatment of nested unions lacking a name, but extended to both structures and unions. A similar capability is provided by the VAX C variant_struct and variant_union types.

For example:

struct{ 
  struct{ 
      int a; 
      int b; 
  };  /*No name here */ 
  int c; 
}d;  /* d.a, d.b, and d.c are valid member names. */ 

1.3.3.2 Block Scope Declaration of static Functions

Allow a static function declaration in block scope (that is, inside another function).

For example:

f(){ 
   static int a(int b); 
} 

1.3.3.3 Treat &* as Having No Effect

Standard C does not allow the & operator to produce an lvalue expression. The Microsoft relaxation allows & to produce an lvalue in certain cases.

For example:

int *a, *b; 
 
f() { 
 
  &*a=b; 
 
} 

1.3.3.4 char is Not Treated as a Unique Type

Treat the char type as either signed char or unsigned char , depending on the default in effect.

For example, a pointer to char can be assigned to a pointer to signed char , assuming the command-line default of /NOUNSIGNED_CHAR:

signed char *a; 
char *b; 
 
f() { 
b=a; 
} 

1.3.3.5 Double Semicolons in Declarations

Suppress warning messages for declarations that contain two semicolons. (That is, allow completely empty declarations at file scope.)

For example:

int a;; 

1.3.3.6 Declaration without a Type

Suppress warning messages for declarations that contain a variable name but no type.

For example:

b; 

1.3.3.7 Enumerators in an Enumeration Declaration

Ignore any extra comma at the end of the last enumerator in an enumeration declaration.

For example:

enum E {a, b, c,};    /*  Ignore the comma after "c". */ 

1.3.3.8 Useless Typedefs

Allow typedef s that have a type specifier but no identifier name declaring the new type.

For example:

typedef struct { int a; }; 

1.3.3.9 Unrecognized Pragmas Accepted

Suppress warning messages when one of the following unsupported Microsoft pragmas is encountered:

#pragma code_seg 
#pragma warning 

1.3.4 CC Command Qualifiers

The following list shows all the command qualifiers and their defaults available with the CC command. A description of each qualifier follows the list.

You can place command qualifiers either on the CC command line itself or on individual file specifications (with the exception of the /LIBRARY qualifier). If placed on a file specification, the qualifier affects only the compilation of the specified source file and all subsequent source files in the compilation unit. If placed on the CC command line, the qualifier affects all source files in all compilation units unless it is overridden by a qualifier on an individual file specification.

/ACCEPT=(option[,option])

Allows the compiler to accept C language syntax that it might not normally accept.

HP C accepts slightly different syntax depending upon the compilation mode specified with the /STANDARD qualifier. The /ACCEPT qualifier can fine tune the language syntax accepted by each /STANDARD mode.

The following qualifier options can be specified:

Table 1-1 /ACCEPT Qualifier Options

Option	Usage
[NO]C99_KEYWORDS	Controls whether or not the C99 Standard keywords inline and restrict (which are are in the C89 namespace for user identifiers) are accepted without double leading underscores. The spelling with two leading underscores ( __inline , __restrict ) is in the namespace reserved to the compiler implementation and is always recognized as a keyword regardless of this option.
[NO]GCCINLINE	The gcc compiler implements an inline function qualifier for functions with external linkage that gives similar capabilites as the C99 extern inline feature for functions, but the usage details are somewhat different: the combination of extern and inline keywords makes an inline definition, instead of the exlusive use of the inline keyword without the extern keyword. This option controls which variation of the feature is implemented. The default in all compiler modes is NOGCCINLINE.
[NO]RESTRICT_KEYWORD	Controls whether or not the compiler recognizes the C99 standard restrict keyword regardless of the /STANDARD mode used. This only affects recognition of the spelling of the keyword as proposed for inclusion in the C99 standard. The spelling with two leading underscores, __restrict , is in the namespace reserved to the compiler implementation and is always recognized as a keyword regardless of this option. Note that [NO]RESTRICT_KEYWORD is a subset of [NO]C99_KEYWORDS. They have the same compiler-mode defaults.
[NO]TRIGRAPHS	Turns trigraph processing on or off. In COMMON and VAXC modes, trigraphs are disabled by default. In all other modes, they are enabled by default.
[NO]VAXC_KEYWORDS	Controls whether or not the compiler recognizes the VAX C keywords (such as "readonly") regardless of the /STANDARD mode used.

The default values are based upon the settings of the /STANDARD qualifier:

• For /STANDARD=RELAXED, the default is:
  /ACCEPT=(VAXC_KEYWORDS,C99_KEYWORDS,NOGCCINLINE,TRIGRAPHS)
• For /STANDARD=VAXC, the default is:
  /ACCEPT=(VAXC_KEYWORDS,NOC99_KEYWORDS,NOGCCINLINE,NOTRIGRAPHS)
• For /STANDARD=COMMON, the default is:
  /ACCEPT=(NOVAXC_KEYWORDS,NOC99_KEYWORDS,NOGCCINLINE,NOTRIGRAPHS)
• For /STANDARD=C99 or /STANDARD=LATEST, the default is:
  /ACCEPT=(NOVAXC_KEYWORDS,C99_KEYWORDS,NOGCCINLINE,TRIGRAPHS)
• In all other modes, the default is:
  /ACCEPT=(NOVAXC_KEYWORDS,NOC99_KEYWORDS,NOGCCINLINE,TRIGRAPHS)

/[NO]ANALYSIS_DATA[=file-spec]

Generates a file of source-code analysis information. The default file name is the file name of the primary source file; the default file type is .ANA. The .ANA file is reserved for use with HP layered products. The default is /NOANALYSIS_DATA. For more information, see Appendix C.

/[NO]ANNOTATIONS[=option]

Controls whether or not the source listing file is annotated with indications of specific optimizations performed or, in some cases, not performed. These annotations can be helpful in understanding the optimization process.

If annotations are requested (and the /LISTING qualifier appears on the command line), the source listing section is shifted to the right and annotation numbers are added to the left of source lines. These numbers refer to brief descriptions that appear later in the source listing file.

Select one or more of the /ANNOTATIONS qualifier options shown in Table 1-2.

Table 1-2 /ANNOTATIONS Qualifier Options

Option	Usage
ALL	Selects all annotations. This output can be quite verbose because it includes detailed output for all annotations. For more concise output for each kind of annotation, use /ANNOTATIONS=(ALL,NODETAIL), or just /ANNOTATIONS with no qualifier options.
[NO]CODE	Annotates the machine-code listing with descriptions of special instructions used for prefetching, alignment, and so on. The /MACHINE_CODE qualifier must also be specified for /ANNOTATION=CODE to have any visible effect.
[NO]DETAIL	Provides additional level of annotation detail, where available.
[NO]FEEDBACK	Indicates use of profile-directed feedback optimizations. Feedback optimizations are not implemented on OpenVMS systems, so this keyword has no visible effect.
[NO]INLINING	Indicates where code for a called procedure was expanded inline.
[NO]LOOP_TRANSFORMS	Indicates optimizations such as loop reordering and code hoisting.
[NO]LOOP_UNROLLING	Indicates where advanced loop nest optimizations have been applied to improve cache performance (unroll and jam, loop fusion, loop interchange, and so on).
[NO]PREFETCHING	Indicates where special instructions were used to reduce memory latency.
[NO]SHRINKWRAPPING	Indicates removal of code establishing routine context when it is not needed.
[NO]SOFTWARE_PIPELINING	Indicates where loops have been scheduled to hide functional unit latency.
[NO]TAIL_CALLS	Indicates an optimization where a call from routine A to B can be replaced by a jump.
[NO]TAIL_RECURSION	Indicates an optimization that eliminates unnecessary routine context for a recursive call.
NONE	Same as /NOANNOTATIONS.

---

Previous

Next

Contents

Index