C Implementation-Defined Behavior. IBM Power10

Chapter 4: C Implementation-Defined Behavior 509

4 C Implementation-Defined Behavior

A conforming implementation of ISO C is required to document its choice of behavior in each of the areas that are designated “implementation defined”. The following lists all such areas, along with the section numbers from the ISO/IEC 9899:1990, ISO/IEC 9899:1999 and ISO/IEC 9899:2011 standards. Some areas are only implementation-defined in one version of the standard.

Some choices depend on the externally determined ABI for the platform (including standard character encodings) which GCC follows; these are listed as “determined by ABI” below. See

Chapter 9 [Binary Compatibility], page 911

, and https: / / gcc . gnu . org / readings.html

. Some choices are documented in the preprocessor manual. See Section

“Implementation-defined behavior” in The C Preprocessor .

Some choices are made by the library and operating system (or other environment when compiling for a freestanding environment); refer to their documentation for details.

4.1 Translation

• How a diagnostic is identified (C90 3.7, C99 and C11 3.10, C90, C99 and C11 5.1.1.3).

Diagnostics consist of all the output sent to stderr by GCC.

• Whether each nonempty sequence of white-space characters other than new-line is retained or replaced by one space character in translation phase 3 (C90, C99 and C11

5.1.1.2).

See Section “Implementation-defined behavior” in The C Preprocessor .

4.2 Environment

The behavior of most of these points are dependent on the implementation of the C library, and are not defined by GCC itself.

• The mapping between physical source file multibyte characters and the source character set in translation phase 1 (C90, C99 and C11 5.1.1.2).

See Section “Implementation-defined behavior” in The C Preprocessor .

4.3 Identifiers

• Which additional multibyte characters may appear in identifiers and their correspondence to universal character names (C99 and C11 6.4.2).

See Section “Implementation-defined behavior” in The C Preprocessor .

• The number of significant initial characters in an identifier (C90 6.1.2, C90, C99 and

C11 5.2.4.1, C99 and C11 6.4.2).

For internal names, all characters are significant. For external names, the number of significant characters are defined by the linker; for almost all targets, all characters are significant.

• Whether case distinctions are significant in an identifier with external linkage (C90

6.1.2).

This is a property of the linker. C99 and C11 require that case distinctions are always significant in identifiers with external linkage and systems without this property are not supported by GCC.

510 Using the GNU Compiler Collection (GCC)

4.4 Characters

• The number of bits in a byte (C90 3.4, C99 and C11 3.6).

Determined by ABI.

• The values of the members of the execution character set (C90, C99 and C11 5.2.1).

Determined by ABI.

• The unique value of the member of the execution character set produced for each of the standard alphabetic escape sequences (C90, C99 and C11 5.2.2).

Determined by ABI.

• The value of a char object into which has been stored any character other than a member of the basic execution character set (C90 6.1.2.5, C99 and C11 6.2.5).

Determined by ABI.

• Which of signed char or unsigned char has the same range, representation, and behavior as “plain” char (C90 6.1.2.5, C90 6.2.1.1, C99 and C11 6.2.5, C99 and C11

6.3.1.1).

Determined by ABI. The options ‘ -funsigned-char ’ and ‘ -fsigned-char ’ change the default. See

Section 3.4 [Options Controlling C Dialect], page 43 .

• The mapping of members of the source character set (in character constants and string literals) to members of the execution character set (C90 6.1.3.4, C99 and C11 6.4.4.4,

C90, C99 and C11 5.1.1.2).

Determined by ABI.

• The value of an integer character constant containing more than one character or containing a character or escape sequence that does not map to a single-byte execution character (C90 6.1.3.4, C99 and C11 6.4.4.4).

See Section “Implementation-defined behavior” in The C Preprocessor .

• The value of a wide character constant containing more than one multibyte character or a single multibyte character that maps to multiple members of the extended execution character set, or containing a multibyte character or escape sequence not represented in the extended execution character set (C90 6.1.3.4, C99 and C11 6.4.4.4).

See Section “Implementation-defined behavior” in The C Preprocessor .

• The current locale used to convert a wide character constant consisting of a single multibyte character that maps to a member of the extended execution character set into a corresponding wide character code (C90 6.1.3.4, C99 and C11 6.4.4.4).

See Section “Implementation-defined behavior” in The C Preprocessor .

• Whether differently-prefixed wide string literal tokens can be concatenated and, if so, the treatment of the resulting multibyte character sequence (C11 6.4.5).

Such tokens may not be concatenated.

• The current locale used to convert a wide string literal into corresponding wide character codes (C90 6.1.4, C99 and C11 6.4.5).

See Section “Implementation-defined behavior” in The C Preprocessor .

• The value of a string literal containing a multibyte character or escape sequence not represented in the execution character set (C90 6.1.4, C99 and C11 6.4.5).

See Section “Implementation-defined behavior” in The C Preprocessor .

Chapter 4: C Implementation-Defined Behavior 511

• The encoding of any of wchar_t , char16_t , and char32_t where the corresponding standard encoding macro ( __STDC_ISO_10646__ , __STDC_UTF_16__ , or __STDC_UTF_

32__ ) is not defined (C11 6.10.8.2).

See Section “Implementation-defined behavior” in The C Preprocessor .

char16_t and char32_t literals are always encoded in UTF-16 and UTF-32 respectively.

4.5 Integers

• Any extended integer types that exist in the implementation (C99 and C11 6.2.5).

GCC does not support any extended integer types.

• Whether signed integer types are represented using sign and magnitude, two’s complement, or one’s complement, and whether the extraordinary value is a trap representation or an ordinary value (C99 and C11 6.2.6.2).

GCC supports only two’s complement integer types, and all bit patterns are ordinary values.

• The rank of any extended integer type relative to another extended integer type with the same precision (C99 and C11 6.3.1.1).

GCC does not support any extended integer types.

• The result of, or the signal raised by, converting an integer to a signed integer type when the value cannot be represented in an object of that type (C90 6.2.1.2, C99 and

C11 6.3.1.3).

For conversion to a type of width N , the value is reduced modulo 2 N of the type; no signal is raised.

to be within range

• The results of some bitwise operations on signed integers (C90 6.3, C99 and C11 6.5).

Bitwise operators act on the representation of the value including both the sign and value bits, where the sign bit is considered immediately above the highest-value value bit. Signed ‘ >> ’ acts on negative numbers by sign extension.

As an extension to the C language, GCC does not use the latitude given in C99 and C11 only to treat certain aspects of signed ‘ << ’ as undefined. However, ‘ -fsanitize=shift ’

(and ‘ -fsanitize=undefined ’) will diagnose such cases. They are also diagnosed where constant expressions are required.

• The sign of the remainder on integer division (C90 6.3.5).

GCC always follows the C99 and C11 requirement that the result of division is truncated towards zero.

4.6 Floating Point

• The accuracy of the floating-point operations and of the library functions in <math.h> and <complex.h> that return floating-point results (C90, C99 and C11 5.2.4.2.2).

The accuracy is unknown.

• The rounding behaviors characterized by non-standard values of FLT_ROUNDS

(C90, C99 and C11 5.2.4.2.2).

GCC does not use such values.

512 Using the GNU Compiler Collection (GCC)

• The evaluation methods characterized by non-standard negative values of FLT_EVAL_

METHOD (C99 and C11 5.2.4.2.2).

GCC does not use such values.

• The direction of rounding when an integer is converted to a floating-point number that cannot exactly represent the original value (C90 6.2.1.3, C99 and C11 6.3.1.4).

C99 Annex F is followed.

• The direction of rounding when a floating-point number is converted to a narrower floating-point number (C90 6.2.1.4, C99 and C11 6.3.1.5).

C99 Annex F is followed.

• How the nearest representable value or the larger or smaller representable value immediately adjacent to the nearest representable value is chosen for certain floating constants (C90 6.1.3.1, C99 and C11 6.4.4.2).

C99 Annex F is followed.

• Whether and how floating expressions are contracted when not disallowed by the FP_

CONTRACT pragma (C99 and C11 6.5).

Expressions are currently only contracted if ‘ -ffp-contract=fast ’,

‘ -funsafe-math-optimizations ’ or ‘ -ffast-math ’ are used.

This is subject to change.

• The default state for the FENV_ACCESS pragma (C99 and C11 7.6.1).

This pragma is not implemented, but the default is to “off” unless ‘ -frounding-math ’ is used in which case it is “on”.

• Additional floating-point exceptions, rounding modes, environments, and classifications, and their macro names (C99 and C11 7.6, C99 and C11 7.12).

This is dependent on the implementation of the C library, and is not defined by GCC itself.

• The default state for the FP_CONTRACT pragma (C99 and C11 7.12.2).

This pragma is not implemented.

Expressions are currently only contracted if

‘ -ffp-contract=fast ’, ‘ -funsafe-math-optimizations ’ or ‘ -ffast-math ’ are used.

This is subject to change.

• Whether the “inexact” floating-point exception can be raised when the rounded result actually does equal the mathematical result in an IEC 60559 conformant implementation (C99 F.9).

This is dependent on the implementation of the C library, and is not defined by GCC itself.

• Whether the “underflow” (and “inexact”) floating-point exception can be raised when a result is tiny but not inexact in an IEC 60559 conformant implementation (C99 F.9).

This is dependent on the implementation of the C library, and is not defined by GCC itself.

4.7 Arrays and Pointers

• The result of converting a pointer to an integer or vice versa (C90 6.3.4, C99 and C11

6.3.2.3).

Chapter 4: C Implementation-Defined Behavior 513

A cast from pointer to integer discards most-significant bits if the pointer representation is larger than the integer type, sign-extends 1 if the pointer representation is smaller than the integer type, otherwise the bits are unchanged.

A cast from integer to pointer discards most-significant bits if the pointer representation is smaller than the integer type, extends according to the signedness of the integer type if the pointer representation is larger than the integer type, otherwise the bits are unchanged.

When casting from pointer to integer and back again, the resulting pointer must reference the same object as the original pointer, otherwise the behavior is undefined.

That is, one may not use integer arithmetic to avoid the undefined behavior of pointer arithmetic as proscribed in C99 and C11 6.5.6/8.

• The size of the result of subtracting two pointers to elements of the same array (C90

6.3.6, C99 and C11 6.5.6).

The value is as specified in the standard and the type is determined by the ABI.

4.8 Hints

• The extent to which suggestions made by using the register storage-class specifier are effective (C90 6.5.1, C99 and C11 6.7.1).

The register specifier affects code generation only in these ways:

• When used as part of the register variable extension, see

Section 6.47.5 [Explicit

Register Variables], page 701 .

• When ‘ -O0 ’ is in use, the compiler allocates distinct stack memory for all variables that do not have the register storage-class specifier; if register is specified, the variable may have a shorter lifespan than the code would indicate and may never be placed in memory.

• On some rare x86 targets, setjmp doesn’t save the registers in all circumstances.

In those cases, GCC doesn’t allocate any variables in registers unless they are marked register .

• The extent to which suggestions made by using the inline function specifier are effective

(C99 and C11 6.7.4).

GCC will not inline any functions if the ‘ -fno-inline ’ option is used or if ‘ -O0 ’ is used. Otherwise, GCC may still be unable to inline a function for many reasons; the

‘ -Winline ’ option may be used to determine if a function has not been inlined and why not.

4.9 Structures, Unions, Enumerations, and Bit-Fields

• A member of a union object is accessed using a member of a different type (C90 6.3.2.3).

The relevant bytes of the representation of the object are treated as an object of the type used for the access. See

[Type-punning], page 187

. This may be a trap representation.

• Whether a “plain” int bit-field is treated as a signed int bit-field or as an unsigned int bit-field (C90 6.5.2, C90 6.5.2.1, C99 and C11 6.7.2, C99 and C11 6.7.2.1).

1

Future versions of GCC may zero-extend, or use a target-defined ptr_extend pattern. Do not rely on sign extension.

514 Using the GNU Compiler Collection (GCC)

By default it is treated as signed int but this may be changed by the

‘ -funsigned-bitfields ’ option.

• Allowable bit-field types other than _Bool , signed int , and unsigned int (C99 and

C11 6.7.2.1).

Other integer types, such as long int , and enumerated types are permitted even in strictly conforming mode.

• Whether atomic types are permitted for bit-fields (C11 6.7.2.1).

Atomic types are not permitted for bit-fields.

• Whether a bit-field can straddle a storage-unit boundary (C90 6.5.2.1, C99 and C11

6.7.2.1).

Determined by ABI.

• The order of allocation of bit-fields within a unit (C90 6.5.2.1, C99 and C11 6.7.2.1).

Determined by ABI.

• The alignment of non-bit-field members of structures (C90 6.5.2.1, C99 and C11

6.7.2.1).

Determined by ABI.

• The integer type compatible with each enumerated type (C90 6.5.2.2, C99 and C11

6.7.2.2).

Normally, the type is unsigned int if there are no negative values in the enumeration, otherwise int . If ‘ -fshort-enums ’ is specified, then if there are negative values it is the first of signed char , short and int that can represent all the values, otherwise it is the first of unsigned char , unsigned short and unsigned int that can represent all the values.

On some targets, ‘ -fshort-enums ’ is the default; this is determined by the ABI.

4.10 Qualifiers

• What constitutes an access to an object that has volatile-qualified type (C90 6.5.3, C99 and C11 6.7.3).

Such an object is normally accessed by pointers and used for accessing hardware. In most expressions, it is intuitively obvious what is a read and what is a write. For example volatile int *dst = somevalue ; volatile int *src = someothervalue ;

*dst = *src; will cause a read of the volatile object pointed to by src and store the value into the volatile object pointed to by dst . There is no guarantee that these reads and writes are atomic, especially for objects larger than int .

However, if the volatile storage is not being modified, and the value of the volatile storage is not used, then the situation is less obvious. For example volatile int *src = somevalue ;

*src;

According to the C standard, such an expression is an rvalue whose type is the unqualified version of its original type, i.e.

int . Whether GCC interprets this as a read of the

Chapter 4: C Implementation-Defined Behavior 515 volatile object being pointed to or only as a request to evaluate the expression for its side effects depends on this type.

If it is a scalar type, or on most targets an aggregate type whose only member object is of a scalar type, or a union type whose member objects are of scalar types, the expression is interpreted by GCC as a read of the volatile object; in the other cases, the expression is only evaluated for its side effects.

When an object of an aggregate type, with the same size and alignment as a scalar type S , is the subject of a volatile access by an assignment expression or an atomic function, the access to it is performed as if the object’s declared type were volatile

S .

4.11 Declarators

• The maximum number of declarators that may modify an arithmetic, structure or union type (C90 6.5.4).

GCC is only limited by available memory.

4.12 Statements

• The maximum number of case values in a switch statement (C90 6.6.4.2).

GCC is only limited by available memory.

4.13 Preprocessing Directives

See Section “Implementation-defined behavior” in The C Preprocessor , for details of these aspects of implementation-defined behavior.

• The locations within #pragma directives where header name preprocessing tokens are recognized (C11 6.4, C11 6.4.7).

• How sequences in both forms of header names are mapped to headers or external source file names (C90 6.1.7, C99 and C11 6.4.7).

• Whether the value of a character constant in a constant expression that controls conditional inclusion matches the value of the same character constant in the execution character set (C90 6.8.1, C99 and C11 6.10.1).

• Whether the value of a single-character character constant in a constant expression that controls conditional inclusion may have a negative value (C90 6.8.1, C99 and C11

6.10.1).

• The places that are searched for an included ‘ <> ’ delimited header, and how the places are specified or the header is identified (C90 6.8.2, C99 and C11 6.10.2).

• How the named source file is searched for in an included ‘ "" ’ delimited header (C90

6.8.2, C99 and C11 6.10.2).

• The method by which preprocessing tokens (possibly resulting from macro expansion) in a #include directive are combined into a header name (C90 6.8.2, C99 and C11

6.10.2).

• The nesting limit for #include processing (C90 6.8.2, C99 and C11 6.10.2).

516 Using the GNU Compiler Collection (GCC)

• Whether the ‘ # ’ operator inserts a ‘ \ ’ character before the ‘ \ ’ character that begins a universal character name in a character constant or string literal (C99 and C11

6.10.3.2).

• The behavior on each recognized nonSTDC #pragma directive (C90 6.8.6, C99 and C11

6.10.6).

See Section “Pragmas” in The C Preprocessor , for details of pragmas accepted by GCC on all targets. See

Section 6.62 [Pragmas Accepted by GCC], page 867

, for details of target-specific pragmas.

• The definitions for __DATE__ and __TIME__ when respectively, the date and time of translation are not available (C90 6.8.8, C99 6.10.8, C11 6.10.8.1).

4.14 Library Functions

The behavior of most of these points are dependent on the implementation of the C library, and are not defined by GCC itself.

• The null pointer constant to which the macro NULL expands (C90 7.1.6, C99 7.17, C11

7.19).

In <stddef.h> , NULL expands to ((void *)0) . GCC does not provide the other headers which define NULL and some library implementations may use other definitions in those headers.

4.15 Architecture

• The values or expressions assigned to the macros specified in the headers <float.h> ,

<limits.h> , and <stdint.h> (C90, C99 and C11 5.2.4.2, C99 7.18.2, C99 7.18.3, C11

7.20.2, C11 7.20.3).

Determined by ABI.

• The result of attempting to indirectly access an object with automatic or thread storage duration from a thread other than the one with which it is associated (C11 6.2.4).

Such accesses are supported, subject to the same requirements for synchronization for concurrent accesses as for concurrent accesses to any object.

• The number, order, and encoding of bytes in any object (when not explicitly specified in this International Standard) (C99 and C11 6.2.6.1).

Determined by ABI.

• Whether any extended alignments are supported and the contexts in which they are supported (C11 6.2.8).

Extended alignments up to 2 28 (bytes) are supported for objects of automatic storage duration. Alignments supported for objects of static and thread storage duration are determined by the ABI.

• Valid alignment values other than those returned by an Alignof expression for fundamental types, if any (C11 6.2.8).

Valid alignments are powers of 2 up to and including 2 28 .

• The value of the result of the sizeof and _Alignof operators (C90 6.3.3.4, C99 and

C11 6.5.3.4).

Determined by ABI.

Chapter 4: C Implementation-Defined Behavior 517

4.16 Locale-Specific Behavior

The behavior of these points are dependent on the implementation of the C library, and are not defined by GCC itself.