| United States |
|
|
|
| Previous | Contents | Index |
VAX C treats a comment in a macro definition as if the comment were replaced with no characters. This allows comments to paste tokens together, as in the following example:
#define PASTE(X) X/* */1 int PASTE(VAR); |
This example declares the variable var1 . ANSI C requires that comments be treated as if they were replaced by a single space. In Compaq C, therefore, comments cannot be used to concatenate tokens when /STANDARD=ANSI89 or /STANDARD=RELAXED_ANSI89 is specified. (The new operator ## is provided to allow token concatenation in macros.)
Compaq C for OpenVMS Systems continues to replace comments with no characters when /STANDARD=VAXC or /STANDARD=COMMON is specified; and /WARN=ENABLE=CHECK provides a diagnostic to flag comments that are used to concatenate tokens.
For /STANDARD=COMMON and /STANDARD=RELAXED_ANSI89, C++ style comments
(//) are supported.
A.1.3 String Literal Concatenation
Compaq C introduces a new ANSI-compliant feature that allows convenient continuation of string literals. If string literals are separated only by white space, the string literals are concatenated to form one string literal. For example:
fputs("This is really "
"one string literal", stderr);
|
String literal concatenation works for both normal string literals and
wide string literals.
A.1.4 Recursive main() Function
In VAX C, main , or any function using the VAX C main_program option, is not recursively reentrant.
As required by ANSI C, the main function in Compaq C can now be
called recursively.
A.1.5 Trigraph Sequences
ANSI C defines an additional representation of some of the special characters in the C language source abstract character set. These additional representations are sequences of three characters called trigraphs. Table A-1 lists the trigraphs and the character each is mapped to.
| Trigraph | Replacement |
|---|---|
| ??= | # |
| ??( | [ |
| ??/ | \ |
| ??) | ] |
| ??' | ^ |
| ??< | { |
| ??! | | |
| ??> | } |
| ??- | ~ |
Conceptually, every trigraph is removed from the file and its replacement is substituted. Each ? that does not begin one of the trigraphs is not changed. Trigraph processing occurs before tokenization takes place. Thus, even trigraphs in string constants have their replacements substituted.
Trigraph support has the potential to change the meaning of existing C code that unintentionally contains a trigraph in a string literal. However, since such conflicts will be quite rare, there is no facility for disabling trigraph support.
Trigraph support is available in strict and relaxed ANSI C mode.
A.1.6 Alert Escape Sequence
As specified by ANSI C, Compaq C defines a new escape sequence
for the alert character. The escape sequence
\a
represents the ASCII BEL (Ctrl/G) character.
A.1.7 Hexadecimal Escape Sequence
VAX C limits hexadecimal escape sequences to at most 3 hex digits, but ANSI C allows an unlimited number of digits. Compaq C removes the limit imposed by VAX C.
This can cause some programs to behave differently. The string
"\x0012"
is currently interpreted by VAX C as a string with two
characters in it: a Ctrl/A followed by the character "2".
Under ANSI C rules, the string consists of a single character whose
character code is hexadecimal 12 (Ctrl/R). However, this problem is
unlikely to occur in practice.
A.1.8 Invalid Escape Sequences
Compaq C issues a warning message if it encounters an invalid
escape sequence. VAX C did not diagnose such usage.
A.1.9 $ in Macro Names
The dollar sign ($) is not an element of the minimum basic character
set allowed by the ANSI C standard. By a systemwide convention, the
dollar sign identifies DIGITAL reserved identifiers. Compaq C for OpenVMS Systems
supplies header files containing many macros with dollar signs in their
names, and the VAX C compiler predefines some macros with
dollar signs in their names. In strict ANSI C mode, such macros trigger
a warning.
A.1.10 Null Arguments to Macros
In Compaq C, null arguments to a macro produce a BUGCHECK.
VAX C allowed macro arguments to be null.
A.1.11 ANSI C Name Space Conformance
ANSI C strictly controls the name space of C programs, and prohibits compilers or their standard-specified header files from intruding on the name space reserved for user programs. Specifically, the ANSI C Standard requires that compiler extensions begin with an underscore followed by an uppercase letter or another underscore.
This affects VAX C extensions involving additional keywords and predefined macros. It also affects the freedom of Compaq C to add additional macros, variables, and functions to the standard-specified header files, such as <stdio.h> .
The following sections describe how Compaq C solves the reserved
name space problem for extensions involving keywords, predefined
macros, and header file contents.
A.1.11.1 Non-ANSI Keywords
VAX C has several keywords that intrude into the user name space. The Compaq C compiler in strict ANSI C mode (/STANDARD=ANSI89) does not recognize keywords that are VAX C-specific extensions to the language. They are recognized instead as identifier names. As a result, programs that use these extensions as keywords cannot be compiled in strict ANSI C mode without eliciting syntax errors.
Similarly, the Compaq C compiler in VAX C mode and relaxed ANSI C mode does recognize keywords that are VAX C-specific extensions to the language. Therefore, programs that use these names as identifiers cannot be compiled in VAX C or relaxed ANSI C mode without eliciting syntax errors. In relaxed ANSI C mode, the compiler generates a warning for these keywords. When the /STANDARD=ANSI89 qualifier is used, the compiler strictly follows the ANSI C rules about the name space, and does not recognize the old spellings as keywords.
Table A-2 shows the traditional spelling and the new spelling of the keywords affected, as well as their corresponding ANSI-compliant pragmas.
| Keyword | Corresponding ANSI-Compliant Pragma |
|---|---|
| globaldef | #pragma extern_model |
| globalref | #pragma extern_model |
| globalvalue | #pragma extern_model |
| noshare | #pragma extern_model |
| readonly | #pragma extern_model |
Alternate spellings that follow ANSI C rules are added to Compaq C for all VAX C predefined macros. For compatibility, both the old spellings of the predefined macros and the new spellings are recognized by the compiler. However, when the /STANDARD=ANSI89 qualifier is used, the compiler strictly follows the ANSI C rules about the name space, and does not recognize the old spellings as predefined macros. You are encouraged to use the new ANSI C conformant spelling of the macros.
Table A-3 shows the traditional spelling and the new spelling of the predefined macros affected
| Traditional Spelling | New Spelling |
|---|---|
| vax | __ vax |
| vax11c | __ vax11c |
| vaxc | __ vaxc |
| vax | __ vax |
| vax11c | __ vax11c |
| vaxc | __ vaxc |
| vms | __ vms |
| vms | __ vms |
| vms_version | __ vms_version |
| vms_version | __ vms_version |
The ANSI C standard specifies exactly what identifiers in the normal name space are declared by the standard header files. A compiler is not free to declare additional identifiers in a header file unless the identifiers follow defined rules (the identifier must begin with an underscore followed by an uppercase letter or another underscore).
When running the Compaq C compiler on OpenVMS systems in strict ANSI C mode (/STANDARD=ANSI89), versions of the standard header files are included that hide many identifiers that do not follow the rules. The <stdio.h> header file, for example, hides the definition of the macro true . The compiler accomplishes this by predefining the macro __ hide_forbidden_names in strict ANSI C mode.
You can use the command-line qualifier /UNDEFINE="__HIDE_FORBIDDEN_NAMES" to prevent the compiler from predefining this macro, thus including macro definitions of the forbidden names.
The header files are modified to only define additional VAX C names if __ hide_forbidden_names is undefined. For example, <stdio.h> might contain the following:
#ifndef __HIDE_FORBIDDEN_NAMES #define TRUE 1 #endif |
Compaq C for OpenVMS Systems supports the following new system-identification macros:
__ decc
__ alpha
__ alpha
__ alpha_axp
__ 32bits
__ mia
__ stdc __
The following sections describe changes to the data types supported by
Compaq C.
A.1.13.1 signed Reserved Word
Compaq C supports the new reserved word signed to complement unsigned . The signed keyword may be used with the char , short , int , and long keywords to specify the types signed char , signed short , signed int , and signed long . (These types are already supported by VAX C.) The signed keyword can also be used when declaring bit fields to specify explicitly that the bit field is signed.
ANSI C specifies that
signed short
,
signed int
, and
signed long
are the same types as
short
,
int
, and
long
, respectively. However,
signed char
is not the same type as
char
, even though Compaq C uses the same representation for both of
them. This does not affect normal mixing of the two types, but it does
mean that in Compaq C a pointer to
signed char
is not compatible with a pointer to
char
. Note that programs that previously used
signed
as an identifier will now be in error, even in VAX C mode. The
/[NO]UNSIGNED_CHAR qualifier can be used to specify whether
char
is signed or unsigned.
A.1.13.2 Removal of the long float Type
In VAX C,
long float
is a synonym for
double
. Since the ANSI C Standard retires the
long float
specification, Compaq C in strict ANSI C mode diagnoses any use of
long float
as an error. The
long float
type is still accepted as a synonym for
double
in VAX C mode, but it elicits a warning diagnostic to the
effect that this is an obsolete usage.
A.1.13.3 Addition of the long double Type
On OpenVMS VAX systems, Compaq C maps the ANSI C defined long double type to the G_floating or D_floating format, depending on the /FLOAT (or /[NO]G_FLOAT) qualifier used. (VAX ONLY)
On OpenVMS Alpha systems, the long double type defaults to X_floating (/L_DOUBLE_SIZE=128). If /L_DOUBLE_SIZE=64 is specified, the long double type is mapped to G_floating, D_floating, or T-floating, depending on the /FLOAT (or /[NO]G_FLOAT) qualifier used. (ALPHA ONLY)
The
<float.h>
header file is modified to define the appropriate values to describe
the characteristics of this new data type.
A.1.13.4 Addition of Processor-Specific Integer Data Types
Compaq C for OpenVMS Systems supports the following processor-specific integer data types:
These data types are intended for applications that need integer data types of a specific size across platforms that support the data type.
The <ints.h> header file contains typedef s for the signed and unsigned variations of these integer data types. For increased portability, use these typedef s rather than using the built-in data types directly.
Note that the 64-bit integer types are available on OpenVMS Alpha systems but not on OpenVMS VAX systems.
The contents of <ints.h> are:
/*
* <ints.h> - Definitions for platform-specific integer types)
*
*/
#ifndef #__INTS_LOADED
#define #__INTS_LOADED 1
typedef signed char int8;
typedef unsigned char uint8;
typedef signed __int16 int16;
typedef unsigned __int16 uint16;
typedef signed __int32 int32;
typedef unsigned __int32 uint32;
#if defined(__ALPHA)
typedef signed __int64 int64;
typedef unsigned __int64 uint64;
#endif
#endif /* __INTS_LOADED */
|
Compaq C for OpenVMS Systems in strict and relaxed ANSI C mode uses different rules than Compaq C in VAX C mode to determine if two types are identical:
These rules cause the strict and relaxed ANSI C modes to be much more
strict than VAX C mode about type checking.
A.1.15 Composite Types
As required by ANSI C, Compaq C merges type information from two declarations of the same object in the same scope. The declarations are required to be type-compatible and the linkage of the declarations must be such that multiple declarations in the same scope are allowed.
The composite type (the merged type) can be formed only from array or function types. Array types can have their array bounds specified, and function types can have their arguments specified.
For example, consider the following two declarations in the same scope:
extern int f(int (*)(), double (*)[3]); extern int f(int (*)(char *), double (*)[]); |
The resulting type for f is:
extern int f(int (*)(char *), double (*)[3]); |
The VAX C compiler did not support composite types, although it might have appeared to do so. For example, in VAX C, what appears to be a second declaration of a composite function type, is actually a redeclaration of the function. This might have an effect on the compilation. For example, if the first declaration has ellipses and the second declaration does not, a composite type cannot be formed (not allowed by the ANSI C Standard). However, a redeclaration is done.
Since the composite type feature of the ANSI C standard is important
even to those programming in VAX C mode, it is supported in
VAX C mode. Therefore, it is possible to encounter declaration
combinations that compile under VAX C but not under
Compaq C in VAX C mode.
A.1.16 Enumerations Have Type int
For type-checking purposes, VAX C previously considered
enumeration types to be distinct from each other, and from the integer
types, even though enumeration constants and variables have always been
usable as ordinary integers. Since the VAX C model of
enumerations was overly restrictive even from the strong typing point
of view, and since such checking is not common in modern C,
Compaq C does not treat enumerations as a special type.
A.1.17 long double Constants
As specified by ANSI C, Compaq C floating-point constants
suffixed by
l
or
l
have type
long double
. (Currently, VAX C gives such constants type
double
).
A.1.18 Implicit Unsigned Integer Constants
The type of an unsuffixed decimal integer constant is the first type in the following list that can represent its value: int , long int , or unsigned long int .
The type of an unsuffixed octal or hex constant is the first type in the following list that can represent its value: int , unsigned int , long int , or unsigned long int .
| Previous | Next | Contents | Index |
|
