United States    
COMPAQ STORE | PRODUCTS |
SERVICES | SUPPORT | CONTACT US | SEARCH
Compaq C

Compaq C
User's Guide for OpenVMS Systems


Previous Contents Index

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:

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.12 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.

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:

Note

The SYS$COMMON:[DECC$LIB.REFERENCE.DECC$RTLDEF] and SYS$COMMON:[DECC$LIB.REFERENCE.SYS$STARLET_C] directories are only reference areas for your viewing. They are created during the compiler installation from the content of the text libraries. By default, the compiler searches only the text library files for headers; it does not search these reference directories.

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

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.
Command Qualifiers Default
/ACCEPT=(option[,option]) See text.
/[NO]ANALYSIS_DATA[=file-spec] /NOANALYSIS_DATA
/[NO]ANSI_ALIAS (ALPHA ONLY) See text.
/ARCHITECTURE=option (ALPHA ONLY) /ARCHITECTURE=GENERIC
/ASSUME=(option[,...]) See text.
/[NO]CHECK[=(option,...)] (ALPHA ONLY) /NOCHECK
/[NO]COMMENTS=option See text.
/[NO]CROSS_REFERENCE /NOCROSS_REFERENCE
/[NO]DEBUG[=(option[,...])] /DEBUG=(TRACEBACK,
NOSYMBOLS) (ALPHA ONLY)
/DEBUG=(TRACEBACK,NOINLINE,
NOSYMBOLS) (VAX ONLY)
/DECC See text.
/[NO]DEFINE=(identifier[=definition][,...]) /NODEFINE
/[NO]DIAGNOSTICS[=file-spec] /NODIAGNOSTICS
/ENDIAN=option (ALPHA ONLY) /ENDIAN=LITTLE
/[NO]ERROR_LIMIT[=n] /NOERROR_LIMIT
/EXTERN_MODEL=option /EXTERN_MODEL=RELAXED_REFDEF
/FLOAT=option /FLOAT=G_FLOAT (ALPHA ONLY)
/FLOAT=D_FLOAT (VAX ONLY)
/[NO]G_FLOAT /G_FLOAT (ALPHA ONLY)
/NOG_FLOAT (VAX ONLY)
/GRANULARITY=option (ALPHA ONLY) /GRANULARITY=QUADWORD
/[NO]INCLUDE_DIRECTORY=(pathname[,...]) /NOINCLUDE_DIRECTORY
/IEEE_MODE=option (ALPHA ONLY) IEEE_MODE=FAST
/INSTRUCTION_SET=[NO]FLOATING_POINT (ALPHA ONLY) /INSTRUCTION_SET=FLOATING_POINT
/L_DOUBLE_SIZE=option (ALPHA ONLY) /L_DOUBLE_SIZE=128
/LIBRARY See text.
/[NO]LINE_DIRECTIVES /LINE_DIRECTIVES
/[NO]LIST[=file-spec] /NOLIST (interactive mode)
/LIST (batch mode)
/[NO]MACHINE_CODE[=option] /NOMACHINE_CODE
/[NO]MEMBER_ALIGNMENT /MEMBER_ALIGNMENT (ALPHA ONLY)
/NOMEMBER_ALIGNMENT (VAX ONLY)
/[NO]MMS_DEPENDENCIES=option /NOMMS_DEPENDENCIES
/NAMES=option /NAMES=UPPERCASE
/NESTED_INCLUDE_DIRECTORY[=option] /NESTED_INCLUDE_DIRECTORY
=INCLUDE_FILE
/[NO]OBJECT[=file-spec] /OBJECT
/[NO]OPTIMIZE[=(option[,...])] /OPTIMIZE
/PDSC_MASK=option (ALPHA ONLY) See text.
/[NO]PLUS_LIST_OPTIMIZE (ALPHA ONLY) /NOPLUS_LIST_OPTIMIZE
/[NO]POINTER_SIZE=option (ALPHA ONLY) /NOPOINTER_SIZE
/PRECISION[=option] See text.
/[NO]PREFIX_LIBRARY_ENTRIES
[=(option[,...])] See text.
/[NO]PREPROCESS_ONLY[=filename] /NOPREPROCESS_ONLY
/[NO]PROTOTYPES[=(option[,...])] /NOPROTOTYPES
/PSECT_MODEL=[NO]MULTILANGUAGE (ALPHA ONLY) /NOMULTILANGUAGE
/REENTRANCY=option (ALPHA ONLY) /REENTRANCY=TOLERANT
/REPOSITORY=option /See text.
/ROUNDING_MODE=option (ALPHA ONLY) /ROUNDING_MODE=NEAREST
/[NO]SHARE_GLOBALS /NOSHARE_GLOBALS
/SHOW[=(option[,...])] /SHOW=(NOBRIEF,
NOCROSS_REFERENCE,
NODICTIONARY,
NOEXPANSION,
NOINCLUDE,
NOINTERMEDIATE,
NOMESSAGE,
NOSTATISTICS,
NOSYMBOLS,
NOTRANSLATION,
SOURCE,
TERMINAL)
/[NO]STANDARD[=(option[,...])] /NOSTANDARD (equivalent to
/STANDARD=RELAXED_ANSI89 )
/[NO]TIE (ALPHA ONLY) /NOTIE
/[NO]UNDEFINE=(identifier[,...]) /NOUNDEFINE
/[NO]UNSIGNED_CHAR /NOUNSIGNED_CHAR
/VAXC (VAX ONLY) See text.
/[NO]VERSION /NOVERSION
/[NO]WARNINGS[=(option[,...])] /WARNINGS

/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 C9x 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 C9x 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 C9x 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 C9x 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:

/[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 DIGITAL layered products. The default is /NOANALYSIS_DATA. For more information, see Appendix C.

/[NO]ANSI_ALIAS (ALPHA ONLY)

Directs the compiler to assume the ANSI C aliasing rules. By so doing, the compiler has the freedom to generate better optimized code.

The aliasing rules referred to are explained in Section 3.3, paragraphs 20 and 25 of the ANSI C Standard, reprinted as follows:

An object shall have its stored value accessed only by an lvalue that has one of the following types:

  • the declared type of the object,
  • a qualified version of the declared type of the object,
  • a type that is the signed or unsigned type corresponding to the declared type of the object,
  • a type that is the signed or unsigned type corresponding to a qualified version of the declared type of the object,
  • an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union), or
  • a character type.

If your program does not access the same data through pointers of a different type (and for this purpose, signed and qualified versions of an otherwise same type are considered to be the same type), then assuming ANSI C aliasing rules allows the compiler to generate better optimized code.

If your program does access the same data through pointers of a different type (for example, by a "pointer to int " and a "pointer to float "), then you must not allow the compiler to assume ANSI C aliasing rules. Otherwise, incorrect code might be generated.

The default is /NOANSI_ALIAS for the /STANDARD=VAXC and /STANDARD=COMMON compiler modes. The default is /ANSI_ALIAS for all other modes.

/ARCHITECTURE (ALPHA ONLY)

Determines the type of Alpha chip code generated for a particular program. The /ARCHITECTURE qualifier uses the same keyword options (keywords) as the /OPTIMIZE=TUNE qualifier.

Where the /OPTIMIZE=TUNE qualifier is primarily used by certain higher-level optimizations for instruction scheduling purposes, the /ARCHITECTURE qualifier determines the type of code instructions generated for the program unit being compiled.

OpenVMS Version 7.1 and subsequent releases provide an operating system kernel that includes an instruction emulator. This emulator allows new instructions, not implemented on the host processor chip, to execute and produce correct results. Applications using emulated instructions will run correctly, but may incur significant software emulation overhead at runtime.

All Alpha processors implement a core set of instructions. Certain Alpha processor versions include additional instruction extensions.

Select one of the /ARCHITECTURE qualifier options shown in Table 1-2.

Table 1-2 /ARCHITECTURE Qualifier Options
Option Usage
GENERIC Generates code that is appropriate for all Alpha processor generations. This is the default.
HOST Generates code for the processor generation in use on the system being used for compilation.

Running programs compiled with this option on other implementations of the Alpha architecture may encounter instruction-emulation overhead.

EV4 Generates code for the 21064, 21064A, 21066, and 21068 implementations of the Alpha architecture.

Running programs compiled with the EV4 option will run without instruction-emulation overhead on all Alpha processors.

EV5 Generates code for some 21164 chip implementations of the Alpha architecture that use only the base set of Alpha instructions (no extensions).

Running programs compiled with the EV5 option will run without instruction-emulation overhead on all Alpha processors.

EV56 Generates code for some 21164 chip implementations that use the byte and word-manipulation instruction extensions of the Alpha architecture.

Running programs compiled with the EV56 option might incur emulation overhead on EV4 and EV5 processors, but will still run correctly on OpenVMS Version 7.1 (or higher) systems.

PCA56 Generates code for the 21164PC chip implementation that uses the byte- and word-manipulation instruction extensions and multimedia instruction extensions of the Alpha architecture.

Running programs compiled with the PCA56 option might incur emulation overhead on EV4, EV5, and EV56 processors, but will still run correctly on OpenVMS Version 7.1 (or higher) systems.

EV6 Generates code for the first-generation 21264 implementation of the Alpha architecture.
EV67 Generates code for the second-generation 21264 implementation of the Alpha architecture.

/ASSUME=(option,...)

Controls compiler assumptions. You can select one or more of the qualifier options described in Table 1-3.

Table 1-3 /ASSUME Qualifier Options
Option Usage
[NO]ACCURACY_SENSITIVE (ALPHA ONLY) Specifies whether certain code transformations that affect floating-point operations are allowed. These changes may or may not affect the accuracy of the program's results.
[NO]ALIGNED_OBJECTS (ALPHA ONLY) Controls an optimization for dereferencing pointers.
[NO]CLEAN_PARAMETERS (ALPHA ONLY) Controls compiler assumptions about short-integer formal parameters.
[NO]EXACT_CDD_OFFSETS Controls the alignment of Control Data Dictionary records.
[NO]HEADER_TYPE_DEFAULT Controls whether or not the default file-type mechanism for header files is enabled.
[NO]MATH_ERRNO (ALPHA ONLY) Controls whether or not intrinsic code is generated for math functions that set the errno variable.
[NO]POINTERS_TO_GLOBALS (ALPHA ONLY) Controls whether or not the compiler can safely assume that global variables have not had their addresses taken in code that is not visible to the current compilation.
[NO]WEAK_VOLATILE (ALPHA ONLY) Affects the generation of code for assignments to objects that are less than or equal to 16 bits in size that have been declared as volatile.
[NO]WHOLE_PROGRAM (ALPHA ONLY) Asserts to the compiler that except for "well-behaved library routines," the whole program consists only of the single object module being produced by this compilation.
[NO]WRITABLE_STRING_LITERALS Stores string constants in a writable psect. Otherwise, such constants are placed in a nonwritable psect.


Previous Next Contents Index
  

1.800.AT.COMPAQ

privacy and legal statement