United States |
Previous | Contents | Index |
Compaq 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). Compaq C has successfully passed the Plum-Hall test suite for ANSI conformance. In strict ANSI C mode, the Compaq 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 Compaq 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, Compaq 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 Compaq C language. Together
with the ANSI C Standard, this section completely specifies the
Compaq C implementation of the C language. The ANSI C Standard is
referred to as "the Standard" throughout this appendix.
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.
The semantics of the arguments to
main()
, including
envp
, are determined by the programming environment. See your
platform-specific Compaq C documentation for information on
arguments to
main()
.
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.
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.
Translation limits vary across platforms because of differences in the
underlying machine architecture and operating systems. Otherwise,
Compaq C avoids imposing translation limits.
The following lists show the only limits imposed in Compaq C.
Translation limits listed in the Standard, but not in the following
list, are not imposed in Compaq C:
On Tru64 UNIX systems:
On OpenVMS systems:
Compaq 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:
Any limits not found in the previous list are defined as shown in the
Standard.
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:
The following keywords are accepted on Tru64 UNIX systems, but
result in a warning:
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
.
B.1 Diagnostics (§2.1.1.3)
B.2 Hosted Environment (§2.1.2.2)
B.3 Multibyte Characters (§2.2.1.2)
B.4 Escape Sequences (§2.2.2)
B.5 Translation Limits (§2.2.4.1)
B.6 Numerical Limits (§2.2.4.2)
B.7 Keywords (§3.1.1)
The MAIN_PROGRAM option is also available with the VAX C compatibility option on OpenVMS systems. |
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.
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 integral 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 integral 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 integral promotions of
unsigned char
and
unsigned short
to
int
that could be affected by the value-preserving approach for integral
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. Compaq 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.
B.19 Structure and Union Members (§3.3.2.3)
The result of accessing a union member different than the member
holding a value depends on the data types of the members and their
alignment within the union.
B.20 The sizeof Operator (§3.3.3.4)
The type of the
sizeof
operator is
size_t
. Compaq C defines this type, which is the type of integer
required to hold the maximum size of an array, in the
<stddef.h>
header as
unsigned int
.
B.21 Cast Operators (§3.3.4)
The Standard specifies that a pointer can be converted to an integral type, but the size of the integer required and the result are implementation-defined. A pointer occupies the same amount of storage as objects of type int or long (or their unsigned equivalents). Therefore, a pointer can be converted to any of these integer types and back again without changing its value. No scaling takes place, and the representation of the value does not change.
Converting between a pointer and a shorter integer type, such as
char
, is similar to the conversion between an object of
unsigned long
type and a shorted integer type. The high-order bits of the pointer are
discarded. Converting between a shorter integer and a pointer is
similar to the conversion between the shorter integer type and
unsigned long
. The high-order bits of the pointer are filled with copies of the sign
bit if the shorter integer type was signed. Messages are issued for
cast operations of these types under the error-checking compiler option.
B.22 Multiplicative Operators (§3.3.5)
The Standard does not provide portable semantics for the division and remainder operators. Compaq C follows these semantics:
The compiler issues a warning in the following cases of undefined behavior detected at compile time:
Pointers to members of the same array can be subtracted. The result is
the number of elements between the two array members. The type of the
result is
ptrdiff_t
. Compaq C defines this type as
int
.
B.24 Bitwise Shift Operators (§3.3.7)
The result of
E1 >> E2
is
E1
right-shifted
E2
bit positions. If
E1
has a signed type, the value of the result is the shifted value of
E1
with the vacated high-order bits filled with a copy of
E1
's sign bit (arithmetic shift).
B.25 Storage-Class Specifiers (§3.5.1)
The
register
storage-class specifier suggests that access to the object be as fast
as possible.
Specifying
register
is intended to give a variable an increased probability of being stored
in a register. However, compiler register allocation techniques make
using the
register
keyword obsolete. That is, Compaq C accepts and ignores all
register
requests.
B.26 Type Specifiers (§3.5.2)
The combination
long float
is supported as a synonym for
double
for compatibility with common C and VAX C. This combination results in
a warning if compiled with the default mode or the strict ANSI mode.
B.27 Structure and Union Specifiers (§3.5.2.1)
The high-order bit position of an
int
bit field is not treated as a sign bit, except in the VAX C
compatibility mode. In other words, the type
int
designates the same type as
unsigned int
for all bit-field types. In VAX C mode, the type
int
designates the same type as
signed int
for all bit-field types.
B.28 Variant Structures and Unions
Variant structures and unions are VAX C extensions that allow nested structures and unions to be declared as members of the enclosing aggregate. This eliminates the need to specify an intermediate qualifier when referring to those members. These capabilities are only available in VAX C mode.
Your platform-specific Compaq C documentation contains details
about these extensions.
B.29 Structure Alignment
The alignment and size of a structure is affected by the alignment requirements and sizes of the structure components for each platform. A structure can begin on any byte boundary and occupy any integral number of bytes. However, individual architectures or operating systems can specify particular default alignment and padding requirements, which can be overridden by pragmas and command-line options.
On OpenVMS Alpha and Tru64 UNIX systems, nonbit-field structure members are, by default, aligned on natural boundaries.
The default alignment of a structure is the maximum alignment required by any member within the structure. The structure is padded to ensure that the size of a structure, in bytes, is a multiple of its alignment requirement to achieve the appropriate alignment when the structure or union is a member of an array.
The components of a structure are laid out in memory in the order they are declared. The first component has the same address as the entire structure. Padding is introduced between components to satisfy the alignment requirements of individual components.
A bit field can have any integral type. However, the compiler issues a warning with the error-checking option if the type is anything other than int , unsigned int , or signed int . The presence of bit fields causes the alignment of the whole structure or union to be at least the same as that of the bit field's base type.
Bit fields (including zero-length bit fields) not immediately declared following other bit fields have the alignment requirement imposed by their base type. Bit fields are allocated within the alignment unit (of the same size as the bit field's base type) from low-order to high-order.
With #pragma member_alignment in effect, if a bit field immediately follows another bit field, the bits are packed into adjacent space in the same unit, if sufficient space remains. Otherwise, padding is inserted at the end of the first bit field and the second bit field is put into the next unit.
With #pragma nomember_alignment in effect, bit fields are allowed to span storage unit boundaries. Alpha systems default to member_alignment while VAX systems default to nomember_alignment .
Bit fields of base type char cannot be larger than 8 bits. Bit fields of base type short cannot be larger than 16 bits.
OpenVMS VAX systems do not require that structures or structure members be aligned on any particular boundaries; nonbit-field structure members are byte-aligned by default.
The components of a structure are laid out in memory in the order they are declared. The first component has the same address as the entire structure. Each additional component follows its predecessor in the immediately following byte.
Natural alignment of structure members, can be obtained by using the following pragma:
pragma member_alignment |
The Compaq C User's Guide for OpenVMS Systems has examples and diagrams of OpenVMS VAX structure alignment.
Bit fields can have any integral type. However, the compiler issues a warning if /STANDARD=ANSI89 is specified, and the type is other than int , unsigned int , or signed int . Bit fields are allocated within the unit from low order to high order. If a bit field immediately follows another bit field, the bits are packed into adjacent space, even if this overflows into another byte. However, if an unnamed bit field is specified to have length 0, filler is added so the bit field immediately following starts on the next byte boundary.
The Compaq C User's Guide for OpenVMS Systems has examples and diagrams of OpenVMS VAX bit-field alignment.
Previous | Next | Contents | Index |
|