HP OpenVMS Systems

C Programming Language
Content starts here HP C

User's Guide for OpenVMS Systems

Previous Contents Index

A.1.18.2 OpenVMS Alpha Systems

The type of an unsuffixed decimal integer constant is the first type in the following list that can represent its value: int , long int , unsigned long int (only in VAXC, COMMON, ANSI89, and MIA modes), long long int , unsigned long int . (ALPHA ONLY)

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 , unsigned long int , long long int , unsigned long long int . (ALPHA ONLY)

For more information, see the Integer Constants section in Chapter 1 of the HP C Language Reference Manual.

A.1.19 Multibyte and Wide Character Support

To meet the needs of non-European languages with large character sets, the C standard 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.

Standard 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, Standard C supports a fixed-size representation where each character is stored in the same number of bytes. This representation is called wide character support. HP C supports a new form of wide character constant and wide string literal.

A.1.19.1 The Wide Character Type

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

HP 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 standard C, HP 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 HP 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 C Standard, HP 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 HP 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 HP 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 C Standard, HP 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

Standard 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 HP 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

Standard 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 standard C. For example, two structs are assignment-compatible in VAX C only if they are the same size.

The HP C compiler in VAX C mode and common mode is compatible with VAX C in assignment compatibility rules. Other modes follow the stricter standard 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 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 .

Standard C has standardized the first interpretation of a function with formal arguments of narrow types. HP C for OpenVMS Systems uses the standard C interpretation in all modes.

A.1.24 "Address of" Operator

In HP C, if the argument of the unary & operator is an array, the result now has the type "pointer to array". Previously, in VAX C, the result would have the type "pointer to the element type of the array".

A.1.25 Unary Plus

HP C supports the new standard C operator, unary plus (+). This operator returns the value of its operand (possibly widened by the integral promotions).

A.1.26 Relational Operators

As required by standard C, HP C issues a warning (in all modes except VAX C mode) to diagnose a constraint violation if one of the operands of a relational operator is a pointer to a function. For example, the following code would issue a warning:

int (*f)(); 
if (f > NULL) 

Note that it is valid to use the equality operators to compare function pointers.

A.1.27 Assignment Compatibility

Standard C has tighter assignment compatibility rules than those previously enforced by VAX C. (Note that assignment compatibility rules also control function argument passing.) HP C assignment compatibility differs from that of VAX C in the following ways:

  • An error is issued if a structure or union type is assigned to a different structure or union type, except in VAX C mode where it is allowed if the structure or union types have the same size.
  • An error is issued if a non- void pointer type is assigned to a different non- void pointer type, except in VAX C mode where it is allowed.
  • An error is issued if a void pointer type (except for a null constant pointer) is assigned to a pointer to a function (or vice versa), except in VAX C mode where it is allowed.

A.1.28 Declarations

Function prototype support, the new const and volatile type qualifiers, and the void type, were already implemented in VAX C. The following sections describe the additional HP C support that affects declarations. References are to the relevant sections in the C Standard.

A.1.28.1 Implementation Limits

The C Standard requires that an implementation support certain minimum requirements; these are listed in the referenced section. In those cases where VAX C imposes a fixed limit, that limit has always met or exceeded the Standard's requirements, and programs that exceed any of these limits elicit the appropriate errors. In strict ANSI C mode, HP C now issues diagnostics against any source program constructs that exceed any of the Standard limits as well.

A.1.28.2 Identifier Name Length

In strict ANSI C mode, HP C now issues diagnostic messages against declarations of external names in excess of six characters, or external names that are intended to denote different objects but that have the same spelling, and ignores alphabetical case.

A.1.28.3 Diagnosing Empty Declarations

The C Standard invalidates empty declarations, except for two special cases: one involving structure/union tags and the other involving the enumeration type. In strict ANSI C mode, HP C issues an error message against any declaration that does not declare at least one of the following: a declarator, a tag, or the members of an enumeration.

A.1.28.4 Restriction on Placement of Storage-Class Specifiers

The C Standard specifies that allowing the placement of any storage-class specifier other than at the beginning of a declaration is an obsolete feature. In strict ANSI C mode, HP C now issues an informational diagnostic to that effect when appropriate.

A.1.28.5 Diagnosing Old-Style Function Declarations

The C Standard specifies that old-style function declarations and definitions (that is, those not using the function prototype format) are obsolete. Old-style function declarations and definitions cause an informational message to be issued in all modes except VAX C.

A.1.28.6 Function Definitions Using typedef-names

The C Standard restricts the form of the declarator in a function definition: the function type itself may not be inherited from a typedef -name; that is, the declarator must explicitly contain a (possibly empty) parenthesized parameter list. If not, HP C in strict ANSI C mode issues an error message.

A.1.28.7 Initialization

HP C for OpenVMS Systems supports the initialization of unions.

In VAX C, an aggregate initializer consisting of a single item does not have to have the outer braces. The outer braces are required by the C Standard.

HP C allows this case in VAX C mode.

A.1.29 Bit-Field Initialization

The HP C compiler initializes bit-field structure members differently than VAX C does. See Section 4.7.2.

A.1.30 The Preprocessor

The following sections describe the differences between the VAX C and the HP C preprocessors. Most of these differences reflect the HP C preprocessor's conformance to the C Standard. References are to the relevant sections in the C Standard.

Note that most VAX C-specific preprocessor extensions are unaffected by these changes. These extensions continue to be supported quietly in VAX C mode, but elicit appropriate diagnostics in strict ANSI C mode.

A.1.30.1 White Space Appearing Before the #

The C Standard removes the VAX C restriction that requires the # character introducing a preprocessor directive to always appear in column 1 of the source line. In HP C, white space and comments can now precede the # on the same line.

A.1.30.2 The #define Directive and Macro Substitution

Before the C Standard, the lack of a precise definition of the behavior of macro expansion led to a number of inconsistencies among different C implementations. HP C, in adhering to the C Standard, removes these and many other discrepancies by specifying precisely how macro substitution is to be performed:

  • Except when running in VAX C or common mode, macro arguments are not allowed to replace parameters appearing within character strings in the macro definition.
  • Except when running in VAX C or common mode, tokens within a macro definition are not concatenated if they were separated only by a comment; embedded comments are replaced by a blank.
  • In all modes, keywords are allowed to be defined as macros.
  • Macros are not replaced recursively in any mode except VAX C mode.

As required by the C Standard, HP C supports two new operators that can appear only within macro definitions:

  • The # operator takes a macro parameter as its operand and creates a character string from it. Combined with the new rule that adjacent character strings are implicitly concatenated into a single string, this provides the same capability as allowing substitution within strings.
  • The ## operator concatenates the tokens on either side of it into a single token.

The C Standard also makes specific the sequence in which rescanning and further substitution is to take place, and under what conditions substitution does not take place. The C Standard also specifies under what circumstances a macro may be redefined: only benign redefinition is allowed, permitting a macro to be redefined only if the new definition is token-wise identical to the old definition.

A.1.30.3 The #line Directive

The C Standard specifies that macro substitution can occur on the operands of the #line directive, that the line number operand is restricted to the range 1 to 32,767, and that the file name operand must be treated as any character string literal. VAX C did not support macro substitution on this directive, performed no range checking on the line number, and restricted the length of the character string to 255.

HP C supports macro substitution on the #line directive, diagnoses an out-of-range line number (in strict ANSI C mode only), and allows the file name character string to be as long as the maximum length supported by the compiler for ordinary strings. (Note that the C Standard requires support for a minimum of 509 characters in a string, and that HP C supports strings up to 65,535 characters.)

A.1.30.4 The #error Directive

HP C in both strict ANSI C mode and VAX C mode supports the new #error directive required by the C Standard.

A.1.30.5 The #pragma builtins Directive

The #pragma builtins directive is provided for VAX C compatibility.

HP C implements #pragma builtins by including the <builtins.h> header file, and is equivalent to #include <builtins.h> on OpenVMS systems.

This header file contains prototype declarations for the built-in functions that allow them to be used properly. By contrast, VAX C implemented this pragma with special-case code within the compiler, which also supported a #pragma nobuiltins preprocessor directive to turn off the special processing. Because declarations cannot be "undeclared," HP C does not support #pragma nobuiltins . Furthermore, the names of all the built-in functions use a naming convention defined by standard C to be in a namespace reserved to the C language implementation.

A.1.30.6 The #pragma dictionary Directive

The #pragma dictionary preprocessor directive replaces the #dictionary directive, but the latter is still supported in VAX C mode for compatibility.

The #pragma dictionary and #dictionary preprocessor directives now allow you to specify whether all string data type variables should be null-terminated.

A.1.30.7 The #pragma extern_model Directive

The #pragma extern_model directive is added to control the compiler's interpretation of objects that have external linkage. This pragma lets you choose the global symbol model to be used for external variables.

A.1.30.8 The #pragma linkage Directive (ALPHA ONLY)

The #pragma linkage preprocessor directive allows you to specify special linkage types for function calls.

A.1.30.9 The #pragma use_linkage Directive (ALPHA ONLY)

The #pragma use_linkage directive associates a previously defined special linkage with a function.

A.1.30.10 The #pragma message Directive

The #pragma message directive controls the issuance of individual diagnostic messages or groups of messages. Use of this pragma overrides any command-line options that may affect the issuance of messages.

A.1.30.11 The #pragma module Directive

The #pragma module preprocessor directive replaces the #module directive, but the latter is still supported in VAX C mode for compatibility.

A.2 Features Affecting the HP C Run-Time Library and Include Files

This section describes new features pertaining to the standard header files in the HP C Run-Time Library (RTL).

A.2.1 <stddef.h>

The wchar_t type is now added to this header file. The declaration of errno is also removed.

A.2.2 <ctype.h>

Because the C Standard refers to the macros in <ctype.h> as functions, the <ctype.h> header file now includes function prototypes for functions in the HP C RTL that perform the same operations as the macros currently defined in this header file. These functions have been added to the HP C RTL.

The nonstandard toascii macro remains because, according to the C Standard, Section 4.14.2, names beginning with "to" are reserved by the C Standard when <ctype.h> is included.

A.2.3 <fp_class.h>

This header file containing IEEE floating-point class constants has been added to support the new HP C RTL functions fp_class , fp_classf , and fp_classl available on OpenVMS Alpha systems.

A.2.4 <locale.h>

The new standard header file <locale.h> is now supported and includes prototypes for the functions setlocale and localeconv , which have been added to the HP C RTL.

A.2.5 <math.h>

The functions cabs and hypot are no longer defined in the <math.h> header file when the compiler is run in strict ANSI C mode.

A.2.6 <signal.h>

The SIGABRT signal is implemented and defined in the <signal.h> header file. SIG_ATOMIC_T is now defined as char . In strict ANSI C mode, the following are not declared: ssignal , gsignal , kill , pause , sleep , sigvec , sigblock , sigsetmask , sigstack , and sigpause .

In strict ANSI C mode, the names of the ILL_* and FPE_* macros are changed to begin with " SIG " (for example, SIGILL_RESAD_FAULT , SIGFPE_INTOVF_TRAP , and so on) or be removed.

The BADSIG macro is renamed to SIG_ERR .

Previous Next Contents Index