| Previous | Contents | Index |
VAX C has several keywords that intrude into the user name space. The DEC 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 DEC 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 DEC 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 DEC 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 |
DEC C for OpenVMS Systems supports the following new system-identification macros:
The following sections describe changes to the data types supported by
DEC C.
A.1.13.1 signed Reserved Word
DEC 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 DEC 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 DEC 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, DEC 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, DEC 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
DEC 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 */
|
DEC C for OpenVMS Systems in strict and relaxed ANSI C mode uses different rules than DEC 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, DEC 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 DEC 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, DEC C does not treat
enumerations as a special type.
A.1.17 long double Constants
As specified by ANSI C, DEC 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
.
A.1.19 Multibyte and Wide Character Support
To meet the needs of non-European languages with large character sets, ANSI C includes a framework to support characters encoded in multiple bytes. This framework is general enough to support character-processing extensions and character-set encodings already used in Asia, and allows for support for the draft proposed ISO Standard 10646, a multiple octet-coded character set that supports dozens of natural languages.
ANSI C supports natural languages with large character sets by recognizing that normal character constants and string literals can be used to represent multibyte characters. A multibyte character is an encoding of variable-length characters where one, two, or more bytes in the string represents a single character in the natural language. The encoding is allowed to support locking shift states that change the encoding of characters for as long as the shift state holds.
Multibyte characters can occur in comments, character constants, and string literals.
Because string manipulation is very difficult when the character size
varies from character to character, ANSI C supports a fixed-size
representation where each character is stored in the same number of
bytes. This representation is called wide character support.
DEC C supports a new form of wide character constant and wide
string literal.
A.1.19.1 The Wide Character Type
ANSI C requires that wide characters be represented by an integral type, and that there be a typedef named wchar_t for that type in the header <stddef.h> .
DEC C defines
wchar_t
to be
unsigned int
. This allows all character sets supported by ISO 10646 to be supported
simultaneously.
A.1.19.2 Multibyte Characters in Comments, Character Constants, and String Literals
Full multibyte support requires that the compiler be able to determine
whether an individual byte in a multibyte string is a single byte
character or part of a multiple byte character. For example, the
compiler must be able to distinguish between the single byte quote
ending a string literal and a quote that is embedded in a multiple byte
character and does not end the string literal.
A.1.19.3 Wide Character Constants
As required by ANSI C, DEC C supports wide character constants. The form of such a constant is the uppercase letter l , followed by a single quote, followed by a multibyte character, followed by a single quote.
The compiler collects the bytes making up the multibyte character into
a string, and then calls the DEC C RTL
mbtowc
function to convert the multibyte character into a wide character. The
resulting value has type
wchar_t
.
A.1.19.4 Wide String Literals
As required by the ANSI C Standard, DEC C supports wide string literals. The form of such a literal is the same as a normal string literal prefixed by the uppercase letter l .
The compiler collects the bytes making up the wide string literal into
a string, and then calls the DEC C RTL
mbstowcs
function to convert the multibyte characters into wide characters. The
resulting wide character string literal has type array of
wchar_t
.
A.1.20 Usual Arithmetic Conversions
In DEC C, the usual arithmetic conversions now support the
long double
type: if either operand of a binary operator that uses these
conversions is
long double
, then the other operand is converted to
long double
.
A.1.21 Indexing as a Commutative Operator
As required by the ANSI C Standard, DEC C now defines the
array indexing operator, [], as commutative. Thus, if
a
is an array and
i
is an integer, both
a[i]
and
i[a]
are valid.
A.1.22 Cast Operators
ANSI C specifies that result of the cast operator is not an lvalue. However, VAX C does allow the cast operator to produce an lvalue.
The DEC C compiler in VAX C mode allows the cast operator to
produce an lvalue.
A.1.23 Function Calls
The following sections describe changes to function calls.
A.1.23.1 Assignment Compatibility Argument Checking
ANSI C defines a function call made with a prototype in scope as assigning the arguments to the parameters of the function. This means that all of the normal type checking and implied conversions that occur during an assignment take place when calling a function.
VAX C currently follows this model with two exceptions. First, it only performs the required type checking if /STANDARD=PORTABLE is given. Second, the assignment compatibility rules used by VAX C are not as stringent as the rules required by ANSI C. For example, two structs are assignment-compatible in VAX C only if they are the same size.
The DEC C compiler in VAX C mode and common mode is compatible
with VAX C in assignment compatibility rules. Other modes follow the
stricter ANSI C rules, documented in Section A.1.27 of this guide, and
issue the required messages even when /STANDARD=PORTABLE is not
specified.
A.1.23.2 Passing Narrow Types to Old Syntax Functions
Traditionally, a function written in C was always called with widened argument types. (Arguments of narrow types like char , short , or float were passed as the widened types int , int , and double , respectively.) The ANSI C Standard preserves this calling mechanism for functions declared using the old syntax. Functions declared using the new prototype syntax may be called with narrow argument types.
Tradition, however, did not specify how the compiler was to interpret a function definition that declared formal arguments of narrow type. One interpretation was that the widened types actually passed should be converted to the narrow type of the formal declaration by the function in its prologue. Another interpretation was that the compiler should rewrite the formal declarations to match the type of the argument actually passed. For example, under this second interpretation, the compiler would change a declaration of a formal argument of type float to a declaration of type double .
ANSI C has standardized the first interpretation of a function with formal arguments of narrow types. DEC C for OpenVMS Systems uses the ANSI C interpretation in all modes.
| Previous | Next | Contents | Index |