[an error occurred while processing this directive]

HP OpenVMS Systems

C Programming Language
Content starts here HP C

HP C
Language Reference Manual


Previous Contents Index

A.2.3 Statements


statement: (§3.6)
labeled-statement
compound-statement
expression-statement
selection-statement
iteration-statement
jump-statement


labeled-statement: (§3.6.1)
identifier : statement
case constant-expression : statement
default : statement


compound-statement: (§3.6.2)
{ declaration-listopt statement-listopt }


declaration-list: (§3.6.2)
declaration
declaration-list declaration


statement-list: (§3.6.2)
statement
statement-list statement


expression-statement: (§3.6.3)
expressionopt ;


selection-statement: (§3.6.4)
if ( expression ) statement
if ( expression ) statement else statement
switch ( expression) statement


iteration-statement: (§3.6.5)
while ( expression ) statement
do statement while ( expression ) ;
for ( expressionopt ; expressionopt ; expressionopt ) statement


jump-statement: (§3.6.6)
goto identifier ;
continue ;
break ;
return expressionopt ;

A.2.4 External Definitions


translation-unit: (§3.7)
external-declaration
translation-unit external-declaration


external-declaration: (§3.7)
function-definition
declaration


function-definition: (§3.7.1)
declaration-specifiersopt declarator declaration-listopt compound-statement

A.3 Preprocessing Directives


preprocessing-file: (§3.8)
groupopt


group: (§3.8)
group-part
group group-part


group-part: (§3.8)
pp-tokensopt new-line
if-section
control-line


if-section: (§3.8.1)
if-group elif-groupsopt else-groupopt endif-line


if-group: (§3.8.1)
#if constant-expression new-line groupopt
#ifdef identifier new-line groupopt
#ifndef identifier new-line groupopt


elif-groups: (§3.8.1)
elif-group
elif-groups elif-group


elif-group: (§3.8.1)
#elif constant-expression new-line groupopt


else-group: (§3.8.1)
#else new-line groupopt


endif-line: (§3.8.1)
#endif new-line

control-line:


#include pp-tokens new-line (§3.8.2)
#define identifier replacement-list new-line (§3.8.3)
#define identifier (identifier-list)opt replacement-list new-line (§3.8.3)
#undef identifier new-line (§3.8.3)
#line pp-tokens new-line (§3.8.4)
#error pp-tokensopt new-line (§3.8.5)
#pragma pp-tokensopt new-line (§3.8.6)
# new-line (§3.8.7)


lparen: (§3.8.3)
the left parenthesis character without preceding white space


replacement-list: (§3.8.3)
pp-tokensopt


pp-tokens: (§3.8)
preprocessing-token
pp-tokens preprocessing-token


new-line: (§3.8)
the new-line character


Appendix B
ANSI Conformance Summary

HP C conforms to the ANSI standard for the Programming Language C, as specified by the X3J11 Technical Committee and documented in the American National Standard for Information Systems--Programming Language C (document number: X3.159-1989). HP C has successfully passed the Plum-Hall test suite for ANSI conformance. In strict ANSI C mode, the HP C compiler is a conforming implementation as described by the ANSI C Standard in Section 1.7, Compliance: " A conforming hosted implementation shall accept any strictly conforming program. A conforming implementation can have extensions (including additional library functions), provided they do not alter the behavior of any strictly conforming program. "

The ANSI C Standard defines a strictly conforming program as:

" A strictly conforming program shall use only those features of the language and library specified in this Standard. It shall not produce output dependent on any unspecified, undefined, or implementation-defined behavior, and shall not exceed any minimum implementation limit. "

" An implementation shall be accompanied by a document that defines all implementation-defined characteristics and all extensions. "

As with most language definitions, the ANSI C Standard does not encompass the entire definition of the C language available within an implementation. The C implementations currently supported by HP include a number of features that are not defined in the ANSI C Standard.

The rest of this section describes the compiler's functionality in a format mirroring the outline of the ANSI C Standard. The relevant ANSI C Standard section number is shown in parentheses following each heading. If a heading from the ANSI C Standard is missing from this description, HP C conforms to the Standard exactly, without extension or implementation-defined behavior.

The following sections document only the extensions and implementation-defined portions of the HP C language. Together with the ANSI C Standard, this section completely specifies the HP C implementation of the C language. The ANSI C Standard is referred to as "the Standard" throughout this appendix.

B.1 Diagnostics (§2.1.1.3)

A diagnostic message is produced for the first violation of a syntax rule or constraint specified in the Standard. Subsequent violations are reported if they are not hidden by previous violations.

B.2 Hosted Environment (§2.1.2.2)

The semantics of the arguments to main() , including envp , are determined by the programming environment. See your platform-specific HP C documentation for information on arguments to main() .

B.3 Multibyte Characters (§2.2.1.2)

The shift states used for the encoding of multibyte characters are dependent on translation tables available on the local system. A particular character set is supported by the language if the local system's translation tables support it.

B.4 Escape Sequences (§2.2.2)

Elements within a character constant or string literal of the source character set are mapped directly into the elements of the execution character set. Escape sequences other than those defined by the Standard are diagnosed with a warning and the backslash is ignored, so that the character constant's or string literal's value is the same as if the backslash were not present.

B.5 Translation Limits (§2.2.4.1)

Translation limits vary across platforms because of differences in the underlying machine architecture and operating systems. Otherwise, HP C avoids imposing translation limits.

The following lists show the only limits imposed in HP C. Translation limits listed in the Standard, but not in the following list, are not imposed in HP C:

  • 32,767 characters in an internal identifier or a macro name
  • 32,767 characters in a logical or physical source line
  • 32,767 bytes in the representation of a string literal (this limit does not apply to string literals formed as a result of concatenation)

On Tru64 UNIX systems:

  • 1023 significant initial characters in an external identifier. A warning is issued if such an identifier is truncated.

On OpenVMS systems:

  • 31 significant initial characters in an external identifier. A warning is issued if such an identifier is truncated.
  • 253 actual arguments or formal parameters to a function.
  • 1012 bytes in a function argument list.

B.6 Numerical Limits (§2.2.4.2)

HP C's numerical limits are defined in the limits.h and float.h header files. These header files contain the implementation-defined values so that the following descriptions hold:

  • There are 8 bits in a character of the execution character set.
  • The representation and set of values for the type char are the same as that of type signed char . This equivalence can be changed from signed char to unsigned char with a command-line option.
  • On OpenVMS systems, the representation and set of values for the types int and signed int are the same as that for type long (32 bits).
  • On OpenVMS systems, the representation and set of values for the type unsigned int are the same as that for type unsigned long (32 bits).
  • On Tru64 UNIX systems, the long int and unsigned long int types are 64 bits, while int and unsigned int are 32 bits.
  • The representation and set of values for the type long double are the same as that for type double (64 bits).

Any limits not found in the previous list are defined as shown in the Standard.

B.7 Keywords (§3.1.1)

The __inline , __unaligned , and __restrict keywords are supported on OpenVMS Alpha systems and Tru64 UNIX systems.

All VAX C keywords are supported in VAX C mode. They are:

  • _align
  • globaldef
  • globalref
  • globalvalue
  • noshare
  • readonly
  • variant_struct
  • variant_union

The following keywords are accepted on Tru64 UNIX systems, but result in a warning:

  • _align
  • noshare
  • readonly

On Tru64 UNIX systems, globaldef and initialized globalvalue declarations are treated as external definitions. globalref and uninitialized globalvalue declarations are treated as if they were declared extern .

Note

The MAIN_PROGRAM option is also available with the VAX C compatibility option on OpenVMS systems.

B.8 Identifiers (§3.1.2)

An identifier can include the character dollar sign ($). (A warning is given for this in strict ANSI mode.)

On Tru64 UNIX systems, case distinctions are always significant in an identifier with external linkage.

On OpenVMS systems, all identifier names with external linkage are converted to uppercase by default, but this can be controlled with a command-line option.

B.9 Linkages of Identifiers (§3.1.2.2)

An error is reported if, within a translation unit, the same identifier appears with both internal and external linkage.

B.10 Types (§3.1.2.5)

The type char and the type signed char have the same representation and set of values. (If the unsigned compile-time option is specified, then the types char and unsigned char have the same representation and set of values.)

B.11 Integer Constants (§3.1.3.2)

The digits 8 and 9 are permitted as valid octal digits in common C and VAX C modes, but a warning message is issued.

B.12 Character Constants (§3.1.3.4)

A character constant containing more than one character or wide character is diagnosed with a warning under the error-checking compiler option and is stored as an integer value. A character constant with more than one character is represented with the last character in the low-order byte for compatibility with common C. Representation of an integer character constant containing an octal or hexadecimal escape sequence not in the basic execution character set is the value specified by the octal or hexadecimal number in the escape sequence. (Its value is interpreted as a signed or unsigned char , depending on whether the unsigned compile-time option is in effect.)

The type of a wide character constant, wchar_t , is unsigned int .

B.13 String Literals (§3.1.4)

The Standard states that identical string literals need not be distinct, and any attempt to modify a string literal is undefined. Therefore, it is an error to modify either a character-string literal or wide-string literal.

B.14 Operators---Compound Assignment (§3.1.5)

The old form of compound assignment operators (such as =+, =-, =*, =/, and =%) are not defined in the Standard.1 Therefore, in expressions of the form expression =unary_op expression, where the =unary_op would previously have been interpreted as an assignment operator, the =unary_op is now interpreted as two tokens: the assignment operator and the unary_op.

A warning message is issued if the error-checking option is specified for =-, =*, =& and =+ (with no intervening white space) to remind you of this change in meaning. Without the error-checking option, no message is issued.

Note

1 Early versions of C allowed compound assignment operators to be written in reverse form (=+, =-, = *) instead of the defined order (+=, -=, *=). This old form leads to syntactic ambiguities for the compound assignment operators whose second operator was also a valid unary operator.

B.15 Characters and Integers---Value-Preserving Promotions (§3.2.1.1)

Two different approaches to the implementation of integer promotion rules have been taken by earlier versions of C. The first approach is called unsigned preserving, in which unsigned char and unsigned short widen to unsigned int . The second approach is called value preserving, in which unsigned char and unsigned short widen to signed int if the value can be represented; otherwise they widen to unsigned int . The Standard specifies that integer promotions are to be value-preserving. This approach is followed in all modes except common C and VAX C mode, and results in a quiet change to programs depending on unsigned-preserving arithmetic conversions.

To aid the programmer in locating arithmetic conversions that depend on unsigned-preserving rules, any integer promotions of unsigned char and unsigned short to int that could be affected by the value-preserving approach for integer promotions are flagged with the error-checking option.

B.16 Signed and Unsigned Integer Conversions (§3.2.1.2)

If the value of an integer demoted to a signed integer is too large to be represented, the result is truncated with excess high-order bits discarded. This is compatible with common C and VAX C.

Conversions between signed and unsigned integers of the same size involve no representation change.

B.17 Floating and Integral Conversions (§3.2.1.3)

When an integer is converted to a floating-point number that cannot be represented exactly, the result of the conversion is the nearest value that can be represented exactly. This result is the natural result of the conversion on the hardware, and can be higher or lower than the original value.

When a floating-point number is converted at compile time to an integer or another floating-point type, and the result cannot be represented, the compiler issues a diagnostic message.

When an integral number or double floating-point number is converted to a floating-point number that cannot exactly represent the original value, the result is rounded to the nearest value of type float . (For details, see the architecture manual for your platform; for example, the MIPS R-Series Processor Architecture Manual or the VAX Architecture Manual.)

When demoting a double value to float , if the value being converted is in the range of values that can be represented, but not represented exactly, the result is the nearest higher or lower value. HP C rounds the result to the nearest representable float value.

Similar rounding is performed for demotions from long double to double or float .

B.18 Pointer Conversions (§3.2.2.3)

Even if two types have the same representation (such as int and long ), they are still different types. This means that a pointer to int cannot be assigned to a pointer to long without using a cast operation.

This rule is relaxed in the common C and VAX C modes. Pointer conversions do not involve a representation change, but, because of alignment restrictions on some machines, access through an unaligned pointer can result in much slower access time, a machine exception, or unpredictable results.


Previous Next Contents Index