1.3.1.1 Including Header Files

Header files are pieces of source code that typically contain declarations shared among C programs. A header file often declares a set of related functions, as well as defining any types and macros needed for their use.

To make the contents of a header file available to your program, include the header file using the #include preprocessor directive.

The #include directive has three forms. Two of the forms are defined by the ISO C standard and are portable:

• Inclusion using angle brackets to delimit the file to be included:

  #include <file-spec>

• Inclusion using quotation marks to delimit the file to be included:

  #include "file-spec"

The third form is the text-module form. It is specific to OpenVMS systems and is not portable. See Section 5.2.3 for more information on the text-module form of inclusion.

The form of the #include directive used determines where the compiler will look to find the file to be included. Generally, the compiler looks in the following places, in the order listed:

1. Places named on the command line with the /INCLUDE_DIRECTORY qualifier or the /LIBRARY qualifier
2. Places identified through logical names, such as DECC$USER_INCLUDE, DECC$SYSTEM_INCLUDE, DECC$LIBRARY_INCLUDE, and DECC$TEXT_LIBRARY
3. System-defined places such as the SYS$COMMON:[DECC$LIB.INCLUDE.*] directory and the SYS$LIBRARY:DECC$RTLDEF.TLB and SYS$LIBRARY:SYS$STARLET_C.TLB text libraries

You can use the UNUSED message group described in the #pragma message description in Section 5.4.13 to enable messages that report apparently unnecessary #include files (and CDD records). Unlike any other messages, these messages must be enabled on the command line (/WARNINGS=ENABLE=UNUSED), rather than with #pragma message , to be effective.

The Compaq C preprocessor is usually able to determine if a particular #include file that has already been processed once was guarded by the conventional sequence: #ifndef FILE_SEEN, #define FILE_SEEN, #endif .

When the compiler detects this pattern of use the first time a particular file is included, it remembers that fact as well as the name of the macro. The next time the same file is included, the compiler checks to see if the "FILE_SEEN" macro is still defined and, if so, it does not reopen and reread the file. Note that if the initial test is in the form #if !defined instead of #ifndef , then the pattern is not recognized. In a listing file, #include directives that are skipped because of this processing are marked with an "X" just as if the #include line itself were excluded.

See the /INCLUDE_DIRECTORY qualifier in Section 1.3.4 for a more complete description of the search-order rules that Compaq C uses to locate included files.

See the Compaq C Run-Time Library Reference Manual for OpenVMS Systems for information on the header files required to use Compaq C Run-Time Library (RTL) functions and macros.

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 Alpha and OpenVMS VAX 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 Compaq C language interfaces
• *.h header files for the OpenVMS system interfaces
• *.h header files for the Compaq 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 Compaq 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

Compaq 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 Compaq 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 (ALPHA ONLY): 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. Because C99 is a superset of Amendment 1 to the C89 standard, and the default mode of RELAXED_ANSI89 is a superset of C99, the __STDC_VERSION__ macro is now defined with the C99-specified value of 199901L. Only when the ISOC94 keyword is added to the strict ANSI89, MIA, or COMMON modes does the macro take on the Amendment 1 value of 199409L (In the absence of the ISOC94 keyword, the ANSI89, MIA, and COMMON modes do not define the macro at all.)

  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_ANSI mode.

• Relaxed ANSI C: This is the default mode on OpenVMS systems, and is specified by /NOSTANDARD or /STANDARD=RELAXED_ANSI89 on the CC command line. The /STANDARD=RELAXED mode accepts ANSI/ISO C Standard C89 and C99 features, as well as nearly all language extensions (such as additional Compaq 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 ISO C standard, in addition to all extensions that do not specify different semantics for the same constructs.
• 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. 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_ANSI89.
  Specifying /STANDARD=ISOC94 enables digraph processing and defines the predefined macro __STDC_VERSION__=199409L , as specified by Amendment 1 to the C89 standard.
• VAX C compatibility: This mode is enabled by specifying /STANDARD=VAXC. It allows the same language as the ANSI C language, but also supports VAX C extensions that are incompatible with the ANSI 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_ANSI89 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_ANSI89/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.

Compaq 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 Compaq 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 Compaq 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

ANSI 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 Integer and Pointer Comparisons without a Cast

Allow integers and pointers to be compared without a cast.

For example:

int *a,b;

f(){
if (a==b)
   b=1;
}

1.3.3.5 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.6 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.7 Declaration without a Type

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

For example:

b;

1.3.3.8 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.9 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.10 Unrecognized Pragmas Accepted

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

#pragma code_seg
#pragma optimize
#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.

Compaq 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.
[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]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_ANSI89, the default is:
  /ACCEPT=(VAXC_KEYWORDS,C99_KEYWORDS,NOGCCINLINE)
• For /STANDARD=VAXC, the default is:
  /ACCEPT=(VAXC_KEYWORDS,NOC99_KEYWORDS,NOGCCINLINE)
• In all other modes, the default is:
  /ACCEPT=(NOVAXC_KEYWORDS,NOC99_KEYWORDS,NOGCCINLINE)

/[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 Compaq 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.

---

Previous

Next

Contents

Index