ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the development of International Standards through technical committees established by the respective organization to deal with particular fields of technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the work.

The procedures used to develop this document and those intended for its further maintenance are described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types of document should be noted. This document was drafted in accordance with the editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives or www.iec.ch/members_experts/refdocs).

ISO and IEC draw attention to the possibility that the implementation of this document may involve the use of (a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any claimed patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had not received notice of (a) patent(s) which may be required to implement this document. However, implementers are cautioned that this may not represent the latest information, which may be obtained from the patent database available at www.iso.org/patents and patents.iec.ch. ISO and IEC shall not be held responsible for identifying any or all such patent rights.

Any trade name used in this document is information given for the convenience of users and does not constitute an endorsement.

For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions related to conformity assessment, as well as information about ISO’s adherence to the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www.iso.org/iso/foreword.html. In the IEC, see www.iec.ch/understanding-standards.

This document was prepared by Joint Technical Committee ISO/IEC JTC1, Information technology, Subcommittee SC22, Programming languages, their environments and system software interfaces.

This fifth edition cancels and replaces the fourth edition (ISO/IEC 9899:2018), which has been technically revised. The main changes are contained in Annex M.

Any feedback or questions on this document should be directed to the user’s national standards body. A complete listing of these bodies can be found at www.iso.org/members.html and www.iec.ch/national-committees.

With the introduction of new devices and extended character sets, new features could be added to future editions of this document. Subclauses in the language and library clauses warn implementers and programmers of usages which, though valid in themselves, could conflict with future additions.

Certain features are obsolescent, which means that they could be considered for withdrawal in future revisions of this document. They are retained because of their widespread use, but their use in new implementations (for implementation features) or new programs (for language [6.11] or library features [7.35]) is discouraged.

This document is divided into four major subdivisions:

• preliminary elements (Clauses 1–4);
• the characteristics of environments that translate and execute C programs (Clause 5);
• the language syntax, constraints, and semantics (Clause 6);
• the library facilities (Clause 7).

In any given subsequent clause or subclause, there are section delineations in bold to describe the semantics, restrictions, and behaviors of programs for this language and potentially the use of its library clauses in this document:

Syntax

which pertains to the spelling and organization of the language and library;

Constraints

which detail and enumerate various requirements for the correct interpretation of the language and library, typically during translation;

Semantics

which explain the behavior of language features and similar constructs;

Description

which explain the behavior of library usage and similar constructs;

Returns

which describes the effects of constructs provided back to a user of the library;

Runtime-constraints

which detail and enumerate various requirements that are expected to be checked and which shall not be violated, typically during execution;

Environmental limits

which list limitations an implementation may impose on a library or language construct which might otherwise be unlimited;

Recommended practice

which provides guidance and important considerations for implementers of this document.

Examples are provided to illustrate possible forms of the constructions described. Footnotes are provided to emphasize consequences of the rules described in that subclause or elsewhere in this document. References are used to refer to other related subclauses. Recommendations are provided to give advice or guidance to implementers. Annexes define optional features, provide additional information and summarize the information contained in this document. A bibliography lists documents that were referred to during the preparation of this document.

The language clause (Clause 6) is derived from "The C Reference Manual"[15].

The library clause (Clause 7) is based on the 1984 /usr/group Standard[16].

This document specifies the form and establishes the interpretation of programs written in the C programming language. It is designed to promote the portability of C programs among a variety of data-processing systems. It is intended for use by implementers and programmers. It specifies:

• the representation of C programs;
• the syntax and constraints of the C language;
• the semantic rules for interpreting C programs;
• the representation of input data to be processed by C programs;
• the representation of output data produced by C programs;
• the restrictions and limits imposed by a conforming implementation of C.

This document does not specify:

• the mechanism by which C programs are transformed for use by a data-processing system;
• the mechanism by which C programs are invoked for use by a data-processing system;
• the mechanism by which input data are transformed for use by a C program;
• the mechanism by which output data are transformed after being produced by a C program;
• the size or complexity of a program and its data that will exceed the capacity of any specific data-processing system or the capacity of a particular processor;
• all minimal requirements of a data-processing system that is capable of supporting a conforming implementation.

Annex J gives an overview of portability issues that a C program can encounter.

The following documents are referred to in the text in such a way that some or all their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

ISO/IEC 2382:2015, Information technology — Vocabulary.

ISO 4217, Codes for the representation of currencies.

ISO 8601 series, Data elements and interchange formats — Information interchange — Representation of dates and times.

ISO/IEC 10646, Information technology —Universal Coded Character Set (UCS).

ISO/IEC 60559:2020, Information technology — Microprocessor Systems — Floating-Point arithmetic.

ISO 80000–2, Quantities and units — Part 2: Mathematics.

The Unicode Consortium. Unicode Standard Annex, UAX #44, Unicode Character Database [online]. Edited by Ken Whistler. Available at https://www.unicode.org/reports/tr44.

The Unicode Consortium. The Unicode Standard, Derived Core Properties. Available at https://www.unicode.org/Public/UCD/latest/ucd/DerivedCoreProperties.txt.

For the purposes of this document, the terms and definitions given in ISO/IEC 2382, ISO 80000–2, and the following apply.

ISO and IEC maintain terminology databases for use in standardization at the following addresses:

• ISO Online browsing platform: available at https://www.iso.org/obp
• IEC Electropedia: available at https://www.electropedia.org/

Additional terms are defined where they appear in italic type or on the left side of a syntax rule. Terms explicitly defined in this document are not to be presumed to refer implicitly to similar terms defined elsewhere.

access (verb)

⟨execution-time action⟩read or modify the value of an object

Note 1 to entry: Where only one of these two actions is meant, "read" or "modify" is used.

Note 2 to entry: "Modify" includes the case where the new value being stored is the same as the previous value.

Note 3 to entry: Expressions that are not evaluated do not access objects.

alignment

requirement that objects of a particular type be located on storage boundaries with addresses that are particular multiples of a byte (3.7) address

argument

actual argument

DEPRECATED: actual parameter

expression in the comma-separated list bounded by the parentheses in a function call expression, or a sequence of preprocessing tokens in the comma-separated list bounded by the parentheses in a function-like macro invocation

arithmetically negate

produce the negative of a given number

Note 1 to entry: For a floating-point number (5.3.5.3.3), this changes the sign; for an integer, this is equivalent to subtracting from zero.

behavior

external appearance or action

implementation-defined behavior

unspecified behavior where each implementation documents how the choice is made

Note 1 to entry: J.3 gives an overview over properties of C programs that lead to implementation-defined behavior.

EXAMPLE An example of implementation-defined behavior is the propagation of the high-order bit when a signed integer is shifted right.

locale-specific behavior

behavior that depends on local conventions of nationality, culture, and language that each implementation documents

Note 1 to entry: J.4 gives an overview over properties of C programs that lead to locale-specific behavior.

EXAMPLE An example of locale-specific behavior is whether the islower function returns true for characters other than the 26 lowercase Latin letters.

undefined behavior

behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this document imposes no requirements

Note 1 to entry: Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).

Note 2 to entry: J.2 gives an overview over properties of C programs that lead to undefined behavior.

Note 3 to entry: Any other behavior during execution of a program is only affected as a direct consequence of the concrete behavior that occurs when encountering the erroneous or non-portable program construct or data. In particular, all observable behavior (5.2.2.4) appears as specified in this document when it happens before an operation with undefined behavior in the execution of the program.

EXAMPLE An example of undefined behavior is the behavior on dereferencing a null pointer.

unspecified behavior

behavior, that results from the use of an unspecified value, or other behavior upon which this document provides two or more possibilities and imposes no further requirements on which is chosen in any instance

Note 1 to entry: J.1 gives an overview over properties of C programs that lead to unspecified behavior.

EXAMPLE An example of unspecified behavior is the order in which the arguments to a function are evaluated.

bit

unit of data storage in the execution environment large enough to hold an object that can have one of two values

Note 1 to entry: It is possible that each individual bit of an object is not addressable.

byte

addressable unit of data storage large enough to hold any member of the basic character set of the execution environment

Note 1 to entry: Each individual byte of an object is uniquely addressable.

byte array

byte type

non-atomic character type

low-order bit

the least significant bit within a byte

high-order bit

the most significant bit within a byte

character

⟨abstract⟩member of a set of elements used for the organization, control, or representation of data

character

single-byte character

⟨C⟩bit representation that fits in a byte

multibyte character

sequence of one or more bytes representing a member of the extended character set of either the source or the execution environment

Note 1 to entry: The extended character set is a superset of the basic character set.

wide character

value representable by an object of type wchar_t

constraint

restriction, either syntactic or semantic, by which the exposition of language elements is interpreted

correctly rounded result

representation in the result format that is nearest in value, subject to the current rounding mode, to what the result would be given unlimited range and precision

Note 1 to entry: In this document, the words "correctly rounded" may apply to an operation that produces a correctly rounded result.

Note 2 to entry: ISO/IEC 60559 or implementation-defined rules apply for extreme magnitude results if the result format contains infinity.

diagnostic message

message belonging to an implementation-defined subset of the implementation’s message output

forward reference

reference to a subsequent subclause in this document that contains additional information relevant to the subclause containing the reference

implementation

particular set of software, running in a particular translation environment under particular control options, that performs translation of programs for, and supports execution of functions in, a particular execution environment

implementation limit

restriction imposed upon programs by the implementation

memory location

either an object of scalar type, or a maximal sequence of adjacent bit-fields all having nonzero width

Note 1 to entry: Two threads of execution can update and access separate memory locations without interfering with each other.

Note 2 to entry: A bit-field and an adjacent non-bit-field member are in separate memory locations. The same applies to two bit-fields, if one is declared inside a nested structure declaration and the other is not, or if the two are separated by a zero-length bit-field declaration, or if they are separated by a non-bit-field member declaration. It is not safe to concurrently update two non-atomic bit-fields in the same structure if all members declared between them are also (nonzero-length) bit-fields, no matter what the sizes of those intervening bit-fields happen to be.

EXAMPLE A structure declared as

struct {
      char a;
      int b:5, c:11,:0, d:8;
      struct { int ee:8; } e;
}

contains four separate memory locations: The member a, and bit-fields d and e.ee are each separate memory locations, and can be modified concurrently without interfering with each other. The bit-fields b and c together constitute the fourth memory location. The bit-fields b and c cannot be concurrently modified, but b and a, for example, can be.

object

region of data storage in the execution environment, the contents of which can represent values

Note 1 to entry: When referenced, an object can be interpreted as having a particular type; see 6.3.3.1.

parameter

formal parameter

DEPRECATED: formal argument

object declared as part of a function declaration or definition that acquires a value on entry to the function, or an identifier from the comma-separated list bounded by the parentheses immediately following the macro name in a function-like macro definition

recommended practice

specification that is strongly recommended as being in keeping with the intent of the standard, but that may be impractical for some implementations

runtime-constraint

requirement on a program when calling a library function

Note 1 to entry: Despite the similar terms, a runtime-constraint is not a kind of constraint as defined by 3.13, and it is not necessary for it to be diagnosed at translation time.

Note 2 to entry: Implementations that support the extensions in Annex K are required to verify that the runtime-constraints for a library function are not violated by the program; see K.3.1.4.

Note 3 to entry: Implementations that support Annex L are permitted to invoke a runtime-constraint handler when they perform a trap.

value

precise meaning of the contents of an object when interpreted as having a specific type

implementation-defined value

unspecified value where each implementation documents how the choice is made

unspecified value

valid value of the relevant type where this document imposes no requirements on which value is chosen in any instance

indeterminate representation

object representation that either represents an unspecified value or is a non-value representation

non-value representation

an object representation that does not represent a value of the object type

perform a trap

interrupt execution of the program such that no further operations are performed

Note 1 to entry: Fetching a non-value representation permits an implementation to perform a trap but is not required to (see 6.2.6.1).

Note 2 to entry: Implementations that support Annex L are permitted to invoke a runtime-constraint handler when they perform a trap.

$\lceil x\rceil$

ceiling of $x$

the least integer greater than or equal to $x$

EXAMPLE $\lceil 2.4\rceil$ is $3$, $\lceil -2.4\rceil$ is $-2$.

$\lfloor x\rfloor$

floor of $x$

the greatest integer less than or equal to $x$

EXAMPLE $\lfloor 2.4\rfloor$ is $2$, $\lfloor -2.4\rfloor$ is $-3$.

wraparound

the process by which a value is reduced modulo $2^N$, where $N$ is the width of the resulting type

out-of-bounds store

(attempted) access (3.1) that, at run time, for a given computational state, would modify (or, for an object declared volatile, fetch) one or more bytes that lie outside the bounds permitted by this document.

bounded undefined behavior

undefined behavior (3.5.3) that does not perform an out-of-bounds store.

Note 1 to entry: The behavior can perform a trap.

Note 2 to entry: Any values produced can be unspecified values, and the representation of objects that are written to can become indeterminate.

critical undefined behavior

undefined behavior that is not bounded undefined behavior.

Note 1 to entry: The behavior can perform an out-of-bounds store or perform a trap.

In this document, "shall" is to be interpreted as a requirement on an implementation or on a program; conversely, "shall not" is to be interpreted as a prohibition.

If a "shall" or "shall not" requirement that appears outside of a constraint or runtime-constraint is violated, the behavior is undefined. Undefined behavior is otherwise indicated in this document by the words "undefined behavior" or by the omission of any explicit definition of behavior. There is no difference in emphasis among these three; they all describe "behavior that is undefined".

A program that is correct in all other aspects, operating on correct data, containing unspecified behavior shall be a correct program and act in accordance with 5.2.2.4.

The implementation shall not successfully translate a preprocessing translation unit containing a #error preprocessing directive unless it is part of a group skipped by conditional inclusion.

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

EXAMPLE

A strictly conforming program can use conditional features (see 6.10.10.4) provided the use is guarded by an appropriate conditional inclusion preprocessing directive using the related macro. For example:

#ifdef __STDC_IEC_60559_BFP__ /* FE_UPWARD defined */
       /* ... */
       fesetround(FE_UPWARD);
       /* ... */
#endif

The two forms of conforming implementation are hosted and freestanding. A conforming hosted implementation shall accept any strictly conforming program. A conforming freestanding implementation shall accept any strictly conforming program in which the use of the features specified in the library clause (Clause 7) is confined to the contents of the standard headers:

<float.h> <iso646.h> <limits.h>

<stdalign.h> <stdarg.h> <stdbit.h>

<stdbool.h> <stdcountof.h> <stddef.h>

<stdint.h> <stdnoreturn.h>

Additionally, a conforming freestanding implementation shall accept any strictly conforming program where:

• the features specified in the header <string.h> are used, except the following functions:

strcoll, strdup, strerror, strndup, strtok, strxfrm; and/or,

• the selected function memalignment from <stdlib.h> is used.

A conforming implementation may have extensions (including additional library functions), provided they do not alter the behavior of any strictly conforming program.¹⁾

The strictly conforming programs that shall be accepted by a conforming freestanding implementation that defines __STDC_IEC_60559_BFP__ or __STDC_IEC_60559_DFP__ can also use features in the contents of the standard headers <fenv.h>, <math.h>, and the strto* floating-point numeric conversion functions (7.25.2) of the standard header <stdlib.h>, provided the program does not set the state of the FENV_ACCESS pragma to "on".

A conforming program is one that is acceptable to a conforming implementation.²⁾

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

An implementation translates C source files and executes C programs in two data-processing-system environments, which will be called the translation environment and the execution environment in this document. Their characteristics define and constrain the results of executing conforming C programs constructed according to the syntactic and semantic rules for conforming implementations.

NOTE In this clause, only a few of many possible forward references have been noted.

A C program is not required to be translated in its entirety at the same time. The text of the program is kept in units called source files, (or preprocessing files) in this document. A source file together with all the headers and source files included via the preprocessing directive #include is known as a preprocessing translation unit. After preprocessing, a preprocessing translation unit is called a translation unit. Previously translated translation units can be preserved individually or in libraries. The separate translation units of a program communicate by (for example) calls to functions whose identifiers have external linkage, manipulation of objects whose identifiers have external linkage, or manipulation of data files. Translation units may be separately translated and then later linked to produce an executable program.

The precedence among the syntax rules of translation is specified by the following phases.³⁾

1. Physical source file multibyte characters are mapped, in an implementation-defined manner, to the source character set (introducing new-line characters for end-of-line indicators) if necessary.
2. Each instance of a backslash character (\) immediately followed by a new-line character is deleted, splicing physical source lines to form logical source lines. Only the last backslash on any physical source line shall be eligible for being part of such a splice.
3. The source file is decomposed into preprocessing tokens⁴⁾ and sequences of white-space characters (including comments). Each comment is replaced by one space character. New-line characters are retained. Whether each nonempty sequence of white-space characters other than new-line is retained or replaced by one space character is implementation-defined.
4. Preprocessing directives are executed, macro invocations are expanded, and _Pragma unary operator expressions are executed. A #include preprocessing directive causes the named header or source file to be processed from phase 1 through phase 4, recursively. All preprocessing directives are then deleted.
5. Each source character set member and escape sequence in character literals and string literals is converted to the corresponding member of the execution character set. Each instance of a source character or escape sequence for which there is no corresponding member is convertedin an implementation-defined manner to some member of the execution character set other than the null (wide) character.⁵⁾
6. Adjacent string literal tokens are concatenated.
7. White-space characters separating tokens are no longer significant. Each preprocessing token is converted into a token. The resulting tokens are syntactically and semantically analyzed and translated as a translation unit.
8. All external object and function references are resolved. Library components are linked to satisfy external references to functions and objects not defined in the current translation. All such translator output is collected into a program image which contains information needed for execution in its execution environment.

A conforming implementation shall produce at least one diagnostic message (identified in an implementation-defined manner) if a preprocessing translation unit or translation unit contains a violation of any syntax rule or constraint, even if the behavior is also explicitly specified as undefined or implementation-defined. Diagnostic messages are not required to be produced in other circumstances.

EXAMPLE An implementation is required to issue a diagnostic for the translation unit:

char i;
int i;

because in those cases where wording in this document describes the behavior for a construct as being both a constraint error and resulting in undefined behavior, the constraint error is still required to be diagnosed.

An implementation is encouraged to identify the nature of, and where possible localize, each violation. Of course, an implementation is free to produce any number of diagnostic messages, often referred to as warnings, as long as a valid program is still correctly translated. It can also successfully translate an invalid program. Annex I lists a few of the more common warnings.

Two execution environments are defined: freestanding and hosted. In both cases, program startup occurs when a designated C function is called by the execution environment. All objects with static storage duration shall be initialized (set to their initial values) before program startup. The manner and timing of such initialization are otherwise unspecified. Program termination returns control to the execution environment.

In a freestanding environment (in which C program execution can take place without any benefit of an operating system), the name and type of the function called at program startup are implementation-defined. Any library facilities available to a freestanding program, other than the minimal set required by Clause 4, are implementation-defined.

The effect of program termination in a freestanding environment is implementation-defined.

A hosted environment is not required to be provided, but shall conform to the following specifications if present.

The function called at program startup is named main. The implementation declares no prototype for this function. It is defined with a return type of int and with no parameters:

int main(void) { /* ... */ }

int main(int argc, char *argv[]) { /* ... */ }

or using another type that is compatible with one of these two function types, or using some other implementation-defined type.

If they are declared, the parameters to the main function shall obey the following constraints:

• The value of argc shall be nonnegative.
• argv[argc] shall be a null pointer.
• If the value of argc is greater than zero, the array members argv[0] through argv[argc-1] inclusive shall contain pointers to strings, which are given implementation-defined values by the host environment prior to program startup. The intent is to supply to the program information determined prior to program startup from elsewhere in the hosted environment. If the host environment is not capable of supplying strings with letters in both uppercase and lowercase, the implementation shall ensure that the strings are received in lowercase.
• If the value of argc is greater than zero, the string pointed to by argv[0] represents the program name; argv[0][0] shall be the null character if the program name is not available from the host environment. If the value of argc is greater than one, the strings pointed to by argv[1] through argv[argc-1] represent the program parameters.
• The parameters argc and argv and the strings pointed to by the argv array shall be modifiable by the program, and retain their last-stored values between program startup and program termination.

In a hosted environment, a program can use all the functions, macros, type definitions, and objects described in the library clause (Clause 7).

If the return type of the main function is a type compatible with int, a return from the initial call to the main function is equivalent to calling the exit function with the value returned by the main function as its argument;⁶⁾ reaching the } that terminates the main function returns a value of $0$. If the return type is not compatible with int, the termination status returned to the host environment is unspecified.

The semantic descriptions in this document describe the behavior of an abstract machine in which issues of optimization are irrelevant.

An access to an object through the use of an lvalue of volatile-qualified type is a volatile access. A volatile access to an object, modifying an object, modifying a file, or calling a function that does any of those operations are all side effects,⁷⁾ which are changes in the state of the execution environment.

Evaluation of an expression in general includes both value computations and initiation of side effects. Value computation for an lvalue expression includes determining the identity of the designated object.

Sequenced before is an asymmetric, transitive, pair-wise relation between evaluations executed by a single thread, which induces a partial order among those evaluations. Given any two evaluations A and B, if A is sequenced before B, then the execution of A shall precede the execution of B. (Conversely, if A is sequenced before B, then B is sequenced after A.) If A is not sequenced before or after B, then A and B are unsequenced. Evaluations A and B are indeterminately sequenced when A is sequenced either before or after B, but it is unspecified which.⁸⁾ The presence of a sequence point between the evaluation of expressions A and B implies that every value computation and side effect associated with A is sequenced before every value computation and side effect associated with B. (A summary of the sequence points is given in Annex C.)

In the abstract machine, all expressions are evaluated as specified by the semantics. An actual implementation is not required to evaluate part of an expression if it can deduce that its value is not used and that no needed side effects are produced (including any caused by calling a function or through volatile access to an object).

When the processing of the abstract machine is interrupted by receipt of a signal, the values of objects that are neither lock-free atomic objects nor of type volatile sig_atomic_t are unspecified, as is the state of the dynamic floating-point environment. The representation of any object modified by the handler that is neither a lock-free atomic object nor of type volatile sig_atomic_t becomes indeterminate when the handler exits, as does the state of the dynamic floating-point environment if it is modified by the handler and not restored to its original state.

The least requirements on a conforming implementation are:

• Volatile accesses to objects are evaluated strictly according to the rules of the abstract machine.
• At program termination, all data written into files shall be identical to the result that execution of the program according to the abstract semantics would have produced.
• The input and output dynamics of interactive devices shall take place as specified in 7.24.3. The intent of these requirements is that unbuffered or line-buffered output appear as soon as possible, to ensure that prompting messages appear prior to a program waiting for input.

This is the observable behavior of the program.

What constitutes an interactive device is implementation-defined.

More stringent correspondences between abstract and actual semantics may be defined by each implementation.

EXAMPLE 1 An implementation can define a one-to-one correspondence between abstract and actual semantics: at every sequence point, the values of the actual objects would agree with those specified by the abstract semantics. The keyword volatile would then be redundant.

Alternatively, an implementation can perform various optimizations within each translation unit, such that the actual semantics would agree with the abstract semantics only when making function calls across translation unit boundaries. In such an implementation, at the time of each function entry and function return where the calling function and the called function are in different translation units, the values of all externally linked objects and of all objects accessible via pointers therein would agree with the abstract semantics. Furthermore, at the time of each such function entry the values of the parameters of the called function and of all objects accessible via pointers therein would agree with the abstract semantics. In this type of implementation, objects referred to by interrupt service routines activated by the signal function would require explicit specification of volatile storage, as well as other implementation-defined restrictions.

EXAMPLE 2 In executing the fragment

char c1, c2;
/* ... */
c1 = c1 + c2;

the "integer promotions" require that the abstract machine promote the value of each variable to int size and then add the two ints and truncate the sum. Provided the addition of two chars can be done without integer overflow, or with integer overflow wrapping silently to produce the correct result, the actual execution need only produce the same result, possibly omitting the promotions.

EXAMPLE 3 Similarly, in the fragment

float f1, f2;
double d;
/* ... */
f1 = f2 * d;

the multiplication can be executed using float arithmetic if the implementation can ascertain that the result would be the same as if it were executed using double arithmetic (for example, if d were replaced by the literal 2.0, which has type double).

EXAMPLE 4 Implementations employing wide registers are expected to take care to honor appropriate semantics. Values are independent of whether they are represented in a register or in memory. For example, an implicit spilling of a register cannot alter the value. Also, an explicit store and load rounds to the precision of the storage type. In particular, casts and assignments perform their specified conversion. For the fragment

double d1, d2;
float f;
d1 = f = /* expression */;
d2 = (float) /* expression */;

the values assigned to d1 and d2 are required to have been converted to float.

EXAMPLE 5 Rearrangement for floating-point expressions is often restricted because of limitations in precision as well as range. The implementation cannot generally apply the mathematical associative rules for addition or multiplication, nor the distributive rule, because of roundoff error, even in the absence of overflow and underflow. Likewise, implementations cannot generally replace decimal literals to rearrange expressions. In the following fragment, rearrangements suggested by mathematical rules for real numbers are often not valid (see F.9).

double x, y, z;
/* ... */
x = (x * y) * z;  // not equivalent to x *= y * z;
z = (x - y) + y;  // not equivalent to z = x;
z = x + x * y;    // not equivalent to z = x * (1.0 + y);
y = x / 5.0;      // not equivalent to y = x * 0.2;

EXAMPLE 6 To illustrate the grouping behavior of expressions, in the following fragment

int a, b;
/* ... */
a = a + 32760 + b + 5;
a = (((a + 32760) + b) + 5);
a = ((a + b) + 32765);
a = ((a + 32765) + b);
a = (a + (b + 32765));

EXAMPLE 7 The grouping of an expression does not completely determine its evaluation. In the following fragment:

#include <stdio.h>
int sum;
char *p;
/* ... */
sum = sum * 10 - ’0’ + (*p++ = getchar());

sum = (((sum * 10) - ’0’) + ((*(p++)) = (getchar())));

but the actual increment of p can occur at any time between the previous sequence point and the next sequence point (the ;), and the call to getchar can occur at any point prior to the need of its returned value.

Forward references: expressions (6.5.1), type qualifiers (6.7.4), statements (6.8), floating-point environment <fenv.h> (7.6), the signal function (7.14), files (7.24.3).

Under a hosted implementation that does not define __STDC_NO_THREADS__, a program can have more than one thread of execution (or thread) running concurrently. The execution of each thread proceeds as defined by the remainder of this document. The execution of the entire program consists of an execution of all its threads.⁹⁾ Under a freestanding implementation, it is implementationdefined whether a program can have more than one thread of execution.

The value of an object visible to a thread $T$ at a particular point is the initial value of the object, a value stored in the object by $T$, or a value stored in the object by another thread, according to the rules in the rest of this subclause.

NOTE 1 In some cases, there can instead be undefined behavior. Much of this subclause is motivated by the desire to support atomic operations with explicit and detailed visibility constraints. However, it also implicitly supports a simpler view for more restricted programs.

Two expression evaluations conflict if one of them modifies a memory location and the other one reads or modifies the same memory location.

The library defines atomic operations (7.17) and operations on mutexes (7.30.4) that are specially identified as synchronization operations. These operations play a special role in making assignments in one thread visible to another. A synchronization operation on one or more memory locations is one of an acquire operation, a release operation, both an acquire and release operation, or a consume operation. A synchronization operation without an associated memory location is a fence and can be either an acquire fence, a release fence, or both an acquire and release fence. In addition, there are relaxed atomic operations, which are not synchronization operations, and atomic read-modify-write operations, which have special characteristics.

NOTE 2 For example, a call that acquires a mutex will perform an acquire operation on the locations composing the mutex. Correspondingly, a call that releases the same mutex will perform a release operation on those same locations. Informally, performing a release operation on A forces prior side effects on other memory locations to become visible to other threads that later perform an acquire or consume operation on A. Relaxed atomic operations are not included as synchronization operations although, like synchronization operations, they cannot contribute to data races.

All modifications to a particular atomic object $M$ occur in some particular total order, called the modification order of $M$. If $A$ and $B$ are modifications of an atomic object $M$, and $A$ happens before $B$, then $A$ shall precede $B$ in the modification order of $M$, which is defined later in this subclause.

NOTE 3 This states that the modification orders are expected to respect the "happens before" relation.

NOTE 4 There is a separate order for each atomic object. There is no requirement that these can be combined into a single total order for all objects. In general this will be impossible because different threads can observe modifications to different variables in inconsistent orders.

A release sequence headed by a release operation $A$ on an atomic object $M$ is a maximal contiguous sub-sequence of side effects in the modification order of $M$, where the first operation is $A$ and every subsequent operation either is performed by the same thread that performed the release or is an atomic read-modify-write operation.

Certain library calls synchronize with other library calls performed by another thread. In particular, an atomic operation $A$ that performs a release operation on an object $M$ synchronizes with an atomic operation $B$ that performs an acquire operation on $M$ and reads a value written by any side effect in the release sequence headed by $A$.

NOTE 5 Except in the specified cases, reading a later value does not necessarily ensure visibility as described later in this subclause. Such a requirement would sometimes interfere with efficient implementation.

NOTE 6 The specifications of the synchronization operations define when one reads the value written by another. For atomic variables, the definition is clear. All operations on a given mutex occur in a single total order. Each mutex acquisition "reads the value written" by the last mutex release.

An evaluation $A$ carries a dependency¹⁰⁾ to an evaluation $B$ if:

• the value of $A$ is used as an operand of $B$, unless:
  • $B$ is an invocation of the kill_dependency macro,
  • $A$ is the left operand of a && or || operator,
  • $A$ is the left operand of a ?: operator, or
  • $A$ is the left operand of a , operator;

or

• $A$ writes a scalar object or bit-field $M$, $B$ reads from $M$ the value written by $A$, and $A$ is sequenced before $B$, or
• for some evaluation $X$, $A$ carries a dependency to $X$ and $X$ carries a dependency to $B$.

An evaluation $A$ is dependency-ordered before¹¹⁾ an evaluation $B$ if:

An evaluation $A$ inter-thread happens before an evaluation $B$ if $A$ synchronizes with $B$, $A$ is dependency-ordered before $B$, or, for some evaluation $X$:

• $A$ synchronizes with $X$ and $X$ is sequenced before $B$,
• $A$ is sequenced before $X$ and $X$ inter-thread happens before $B$, or
• $A$ inter-thread happens before $X$ and $X$ inter-thread happens before $B$.

NOTE 7 The "inter-thread happens before" relation describes arbitrary concatenations of "sequenced before", "synchronizes with", and "dependency-ordered before" relationships, with two exceptions. The first exception is that a concatenation is not permitted to end with "dependency-ordered before" followed by "sequenced before". The reason for this limitation is that a consume operation participating in a "dependency-ordered before" relationship provides ordering only with respect to operations to which this consume operation carries a dependency. The reason that this limitation applies only to the end of such a concatenation is that any subsequent release operation will provide the required ordering for a prior consume operation. The second exception is that a concatenation is not permitted to consist entirely of "sequenced before". The reasons for this limitation are (1) to permit "inter-thread happens before" to be transitively closed and (2) the "happens before" relation, defined subsequently in this subclause, provides for relationships consisting entirely of "sequenced before".

An evaluation $A$ happens before an evaluation $B$ if $A$ is sequenced before $B$ or $A$ inter-thread happens before $B$. The implementation shall ensure that no program execution demonstrates a cycle in the "happens before" relation.

NOTE 8 This cycle would otherwise be possible only through the use of consume operations.

A visible side effect $A$ on an object $M$ with respect to a value computation $B$ of $M$ satisfies the conditions:

• $A$ happens before $B$, and
• there is no other side effect $X$ to $M$ such that $A$ happens before $X$ and $X$ happens before $B$.

The value of a non-atomic scalar object $M$, as determined by evaluation $B$, shall be the value stored by the visible side effect $A$.

NOTE 9 If there is ambiguity about which side effect to a non-atomic object is visible, then there is a data race and the behavior is undefined.

NOTE 10 This states that operations on ordinary variables are not visibly reordered. This is not detectable without data races, but ensures that data races, as defined here, and with suitable restrictions on the use of atomics, correspond to data races in a simple interleaved (sequentially consistent) execution.

The value of an atomic object $M$, as determined by evaluation $B$, shall be the value stored by some side effect $A$ that modifies $M$, where $B$ does not happen before $A$.

NOTE 11 The set of side effects from which a given evaluation can take its value is also restricted by the rest of the rules described here, and in particular, by the coherence requirements subsequently in this subclause.

If an operation $A$ that modifies an atomic object $M$ happens before an operation $B$ that modifies $M$, then $A$ shall be earlier than $B$ in the modification order of $M$.

NOTE 12 Such a requirement is known as "write-write coherence".

If a value computation $A$ of an atomic object $M$ happens before a value computation $B$ of $M$, and $A$ takes its value from a side effect $X$ on $M$, then the value computed by $B$ shall either be the value stored by $X$ or the value stored by a side effect $Y$ on $M$, where $Y$ follows $X$ in the modification order of $M$.

NOTE 13 Such a requirement is known as "read-read coherence".

If a value computation $A$ of an atomic object $M$ happens before an operation $B$ on $M$, then $A$ shall take its value from a side effect $X$ on $M$, where $X$ precedes $B$ in the modification order of $M$.

NOTE 14 Such a requirement is known as "read-write coherence".

If a side effect $X$ on an atomic object $M$ happens before a value computation $B$ of $M$, then the evaluation $B$ shall take its value from $X$ or from a side effect $Y$ that follows $X$ in the modification order of $M$.

NOTE 15 Such a requirement is known as "write-read coherence".

NOTE 16 This effectively disallows compiler reordering of atomic operations to a single object, even if both operations are "relaxed" loads. By doing so, it effectively makes the "cache coherence" guarantee provided by most hardware available to C atomic operations.

NOTE 17 The value observed by a load of an atomic object depends on the "happens before" relation, which in turn depends on the values observed by loads of atomic objects. The intended reading is that there exists an association of atomic loads with modifications they observe that, together with suitably chosen modification orders and the "happens before" relation derived as described previously, satisfy the resulting constraints as imposed here.

The execution of a program contains a data race if it contains two conflicting actions in different threads, at least one of which is not atomic, and neither happens before the other. Any such data race results in undefined behavior.

NOTE 18 It can be shown that programs that correctly use simple mutexes and memory_order_seq_cst operations to prevent all data races, and use no other synchronization operations, behave as though the operations executed by their constituent threads were simply interleaved, with each value computation of an object being the last value stored in that interleaving. This is normally referred to as "sequential consistency". However, this applies only to data-race-free programs, and data-race-free programs cannot observe most program transformations that do not change single-threaded program semantics. In fact, most single-threaded program transformations continue to be allowed, because any program that behaves differently as a result of such transformations necessarily has undefined behavior even before such a transformation is applied.

NOTE 19 Compiler transformations that introduce assignments to a potentially shared memory location that would not be modified by the abstract machine are generally precluded by this document, because such an assignment can overwrite another assignment by a different thread in cases in which an abstract machine execution would not have encountered a data race. This includes implementations of data member assignment that overwrite adjacent members in separate memory locations. Reordering of atomic loads in cases in which the atomics in question can alias is also generally precluded as this can violate the coherence requirements.

NOTE 20 Transformations that introduce a speculative read of a potentially shared memory location possibly will not preserve the semantics of the program as defined in this document as they potentially introduce a data race. However, they are typically valid in the context of an optimizing compiler that targets a specific machine with well-defined semantics for data races. They would be invalid for a hypothetical machine that is not tolerant of races or provides hardware race detection.

Two sets of characters and their associated collating sequences shall be defined: the set in which source files are written (the source character set), and the set interpreted in the execution environment (the execution character set). Each set is further divided into a basic character set, whose contents are given by this subclause, and a set of zero or more locale-specific members (which are not members of the basic character set) called extended characters. The combined set is also called the extended character set. The values of the members of the execution character set are implementation-defined.

In a character literal or string literal, members of the execution character set shall be represented by corresponding members of the source character set or by escape sequences consisting of the backslash \ followed by one or more characters. A byte with all bits set to $0$, called the null character, shall exist in the basic execution character set; it is used to terminate a character string.

Both the basic source and basic execution character sets shall have the following members: the 26 uppercase letters of the Latin alphabet

The value of each character after a, up to and including f, in the prior specified list of lowercase letters, shall be one greater than the value of the previous.

The value of each character after A, up to and including F, in the prior specified list of uppercase letters, shall be one greater than the value of the previous.

A letter is an uppercase letter or a lowercase letter as defined previously in this subclause; in this document the term does not include other characters that are letters in other alphabets.

The universal character name construct provides a way to name other characters.

The source character set can contain multibyte characters, used to represent members of the extended character set. The execution character set can also contain multibyte characters, which are not required to have the same encoding as for the source character set. For both character sets, the following shall hold:

• The basic character set shall be present and each character shall be encoded as a single byte.
• The presence, meaning, and representation of any additional members is locale-specific.
• A multibyte character set can have a state-dependent encoding, wherein each sequence of multibyte characters begins in an initial shift state and enters other locale-specific shift states when specific multibyte characters are encountered in the sequence. While in the initial shift state, all single-byte characters retain their usual interpretation and do not alter the shift state. The interpretation for subsequent bytes in the sequence is a function of the current shift state.
• A byte with all bits zero shall be interpreted as a null character independent of shift state. Such a byte shall not occur as part of any other multibyte character.

For source files, the following shall hold:

• An identifier, comment, string literal, character literal, or header name shall begin and end in the initial shift state.
• An identifier, comment, string literal, character literal, or header name shall consist of a sequence of valid multibyte characters.

The active position is that location on a display device where the next character output by the fputc function would appear. The intent of writing a printing character (as defined by the isprint function) to a display device is to display a graphic representation of that character at the active position and then advance the active position to the next position on the current line. The direction of writing is locale-specific. If the active position is at the final position of a line (if there is one), the behavior of the display device is unspecified.

Alphabetic escape sequences representing non-graphic characters in the execution character set are intended to produce actions on display devices as follows:

\a (alert) Produces an audible or visible alert without changing the active position.

\b (backspace) Moves the active position to the previous position on the current line. If the active position is at the initial position of a line, the behavior of the display device is unspecified.

\f (form feed) Moves the active position to the initial position at the start of the next logical page.

\n (new line) Moves the active position to the initial position of the next line.

\r (carriage return) Moves the active position to the initial position of the current line.

\t (horizontal tab) Moves the active position to the next horizontal tabulation position on the current line. If the active position is at or past the last defined horizontal tabulation position, the behavior of the display device is unspecified.

\v (vertical tab) Moves the active position to the initial position of the next vertical tabulation position. If the active position is at or past the last defined vertical tabulation position, the behavior of the display device is unspecified.

Each of these escape sequences shall produce a unique implementation-defined value which can be stored in a single char object. The external representations in a text file are not necessarily identical to the internal representations, and are outside the scope of this document.

Functions shall be implemented such that they can be interrupted at any time by a signal, or can be called by a signal handler, or both, with no alteration to earlier, but still active, invocations’ control flow (after the interruption), function return values, or objects with automatic storage duration. All such objects shall be maintained outside the function image (the instructions that compose the executable representation of a function) on a per-invocation basis.

Both the translation and execution environments constrain the implementation of language translators and libraries. The following summarizes the language-related environmental limits on a conforming implementation; the library-related limits are discussed in Clause 7.

The implementation shall be able to translate and execute a program that uses but does not exceed the following limitations for these constructs and entities:¹²⁾

An implementation is required to document all the limits specified in this subclause, which are specified in the headers <limits.h> and <float.h>. Additional limits are specified in <stdint.h>.

Many integer types that are defined in this document have a corresponding width macro with a name ending in _WIDTH.¹⁴⁾ The values of these macros provide the number of bits in the value representation of the type (6.2.6.2). The values given subsequently are replaced by constant expressions suitable for use in conditional expression inclusion preprocessing directives. Those of the values that are implementation-defined are equal or greater to those shown; otherwise the values are exact.

• width for an object of type bool¹⁵⁾

BOOL_WIDTH                       1

• number of bits for smallest object that is not a bit-field (byte)

CHAR_BIT                         8

The macros CHAR_WIDTH, SCHAR_WIDTH, and UCHAR_WIDTH that represent the width of the types char, signed char and unsigned char shall expand to the same value as CHAR_BIT.

• width for an object of type unsigned short int

USHRT_WIDTH                     16

The macro SHRT_WIDTH represents the width of the type short int and shall expand to the same value as USHRT_WIDTH.

• width for an object of type unsigned int

UINT_WIDTH                      16

The macro INT_WIDTH represents the width of the type int and shall expand to the same value as UINT_WIDTH.

• width for an object of type unsigned long int

ULONG_WIDTH                      32

The macro LONG_WIDTH represents the width of the type long int and shall expand to the same value as ULONG_WIDTH.

• width for an object of type unsigned long long int

ULLONG_WIDTH                     64

The macro LLONG_WIDTH represents the width of the type long long int and shall expand to the same value as ULLONG_WIDTH.

• maximum width of a bit-precise integer type

BITINT_MAXWIDTH     /* see the following */

The macro BITINT_MAXWIDTH represents the maximum width N supported by the declaration of a bit-precise integer (6.2.5) in the type specifier _BitInt(N). The value BITINT_MAXWIDTH shall expand to a value that is greater than or equal to the value of ULLONG_WIDTH.

MB_LEN_MAX                       1

For all unsigned integer types for which <limits.h> or <stdint.h> define a macro with suffix _WIDTH holding its width N, there is a macro with suffix _MAX holding the maximal value $2^N-1$ that is representable by the type and that has the same type as would an expression that is an object of the corresponding type converted according to the integer promotions. If the value is in the range of the type uintmax_t (7.23.2.6) the macro is suitable for use in conditional expression inclusion preprocessing directives.

For all signed integer types for which <limits.h> or <stdint.h> define a macro with suffix _WIDTH holding its width $N$, there are macros with suffix _MIN and _MAX holding the minimal and maximal values $-2^{N-1}$ and $2^{N-1}-1$ that are representable by the type and that have the same type as would an expression that is an object of the corresponding type converted according to the integer promotions. If the values are in the range of the type intmax_t (7.23.2.6) the macros are suitable for use in conditional expression inclusion preprocessing directives.

If an object of type char can hold negative values, the value of CHAR_MIN shall be the same as that of SCHAR_MIN and the value of CHAR_MAX shall be the same as that of SCHAR_MAX. Otherwise, the value of CHAR_MIN shall be 0 and the value of CHAR_MAX shall be the same as that of UCHAR_MAX (see 6.2.5.).

The characteristics of floating types are defined in terms of a model that describes a representation of floating-point numbers and allows other values. The characteristics provide information about an implementation’s floating-point arithmetic.¹⁶⁾ An implementation that defines __STDC_IEC_60559_BFP__ or __STDC_IEC_559__ shall implement floating types and arithmetic conforming to ISO/IEC 60559 as specified in Annex F of this document. An implementation that defines __STDC_IEC_60559_COMPLEX__ shall implement complex types and arithmetic conforming to ISO/IEC 60559 as specified in Annex G of this document.

The following parameters are used to define the model for each floating type:

$s$ sign ($\pm 1$) $b$ base or radix of exponent representation (an integer $>1$) $e$ exponent (an integer between a minimum $e_{\min }$ and a maximum $e_{\max }$ ) $p$ precision (the number of base-$b$ digits in the significand) $f_k$ nonnegative integers less than $b$ (the significand digits)

For each floating type, the parameters $b$, $p$, $e_{\min }$ , and $e_{\max }$ are fixed constants.

For each floating type, a floating-point number ($x$) is defined by the following model:

$x={\mathrm{sb}}^e$ $p�$

$k=1$ $f_k{b}^{-k}$, $e_{\min }\le e\le e_{\max }$

Model floating-point numbers $x$ with $f_1>0$ are called normalized floating-point numbers.

Model floating-point numbers $x̸=0$ with $f_1=0$ and $e=e_{\min }$ are called subnormal floating-point numbers.

Model floating-point numbers $x̸=0$ with $f_1=0$ and $e>e_{\min }$ are called unnormalized floating-point numbers.

Model floating-point numbers $x$ with all $f_k=0$ are zeros.

Floating types shall be able to represent signed zeros or an unsigned zero and all normalized floatingpoint numbers. In addition, floating types may be able to contain other kinds of floating-point

NOTE 1 Some implementations have types that include finite numbers with range and/or precision that are not covered by the model.

A NaN is a value signifying Not-a-Number. A quiet NaN propagates through almost every arithmetic operation without raising a floating-point exception; a signaling NaN generally raises a floating-point exception when occurring as an arithmetic operand.

NOTE 2 ISO/IEC 60559 specifies quiet and signaling NaNs. For implementations that do not support ISO/IEC 60559, the terms quiet NaN and signaling NaN are intended to apply to values with similar behavior.

Wherever values are unsigned, any requirement in this document to get the sign shall produce an unspecified sign, and any requirement to set the sign shall be ignored, unless otherwise specified.

NOTE 3 Bit representations of floating-point values can include a sign bit, even if the values can be regarded as unsigned; ISO/IEC 60559 NaNs are such values.

Whether and in what cases subnormal numbers are treated as zeros is implementation-defined. Subnormal numbers that in some cases are treated by arithmetic operations as zeros are properly classified as subnormal. However, object representations that could represent subnormal numbers but that are always treated by arithmetic operations as zeros are non-canonical zeros, and the values are properly classified as zero, not subnormal. ISO/IEC 60559 arithmetic (with default exception handling) always treats subnormal numbers as nonzero.

A value is negative if and only if it compares less than $0$. Thus, negative zeros and NaNs are not negative values.

An implementation can prefer particular representations of values that have multiple representations in a floating type, 6.2.6.1 notwithstanding. The preferred representations of a floating type, including unique representations of values in the type, are called canonical. A floating type can also contain non-canonical representations, for example, redundant representations of some or all its values, or representations that are extraneous to the floating-point model. Typically, floating-point operations deliver results with canonical representations. ISO/IEC 60559 operations deliver results with canonical representations, unless specified otherwise.

NOTE 4 The library operations iscanonical and canonicalize distinguish canonical (preferred) representations, but this distinction alone does not imply that canonical and non-canonical representations are of different values.

NOTE 5 Some of the values in the ISO/IEC 60559 decimal formats have non-canonical representations (as well as a canonical representation).

The minimum range of representable values for a floating type is the most negative finite floatingpoint number representable in that type through the most positive finite floating-point number representable in that type. In addition, if negative infinity is representable in a type, the range of that type is extended to all negative real numbers; likewise, if positive infinity is representable in a type, the range of that type is extended to all positive real numbers.

The accuracy of the floating-point operations (+, -, *, /) and of most of the library functions in <math.h> and <complex.h> that return floating-point results is implementation-defined, as is the accuracy of the conversion between floating-point internal representations and string representations performed by the library functions in <stdio.h>, <stdlib.h>, and <wchar.h>. The implementation may state that the accuracy is unknown. Decimal floating-point operations have stricter requirements.

All integer values in the <float.h> header, except FLT_ROUNDS, shall be constant expressions suitable for use in conditional expression inclusion preprocessing directives; all floating values shall be arithmetic constant expressions. All except CR_DECIMAL_DIG (F.5), DECIMAL_DIG, DEC_EVAL_METHOD, FLT_EVAL_METHOD, FLT_RADIX, and FLT_ROUNDS have separate names for all floating types. The floating-point model representation is provided for all values except DEC_EVAL_METHOD, FLT_EVAL_METHOD and FLT_ROUNDS.

The remainder of this subclause specifies characteristics of standard floating types.

The rounding mode for floating-point addition for standard floating types is characterized by the implementation-defined value of FLT_ROUNDS. Evaluation of FLT_ROUNDS correctly reflects any execution-time change of rounding mode through the function fesetround in <fenv.h>.

$-1$ indeterminable

$0$ toward zero

$1$ to nearest, ties to even

$2$ toward positive infinity

$3$ toward negative infinity

$4$ to nearest, ties away from zero

All other values for FLT_ROUNDS characterize implementation-defined rounding behavior.

Whether a type has the same base ($b$), precision ($p$), and exponent range ($e_{\min }\le e\le e_{\max }$ ) as an ISO/IEC 60559 format is characterized by the implementation-defined values of FLT_IS_IEC_60559, DBL_IS_IEC_60559 and LDBL_IS_IEC_60559 (this does not imply conformance to Annex F):

$0$ type does not have the precision and exponent range of an ISO/IEC 60559 format

$1$ type has the precision and exponent range of an ISO/IEC 60559 format

NOTE 6 Outside of the normalized floating-point numbers, the representability of values (e.g. negative zero) of the ISO/IEC 60559 format is not implied.

The values of floating type yielded by operators subject to the usual arithmetic conversions, including the values yielded by the implicit conversion of operands, and the values of floating literals are evaluated to a format whose range and precision can be greater than required by the type. Such a format is called an evaluation format. In all cases, assignment and cast operators yield values in the format of the type. The extent to which evaluation formats are used is characterized by the value of FLT_EVAL_METHOD:¹⁷⁾

$-1$ indeterminable;

$0$ evaluate all operations and literals just to the range and precision of the type;

$1$ evaluate operations and literals of type float and double to the range and precision of the double type, evaluate long double operations and literals to the range and precision of the long double type;

$2$ evaluate all operations and literals to the range and precision of the long double type.

All other negative values for FLT_EVAL_METHOD characterize implementation-defined behavior. The value of FLT_EVAL_METHOD does not characterize values returned by function calls (see 6.8.7.5, F.6).

The presence or absence of subnormal numbers is characterized by the implementation-defined values of FLT_HAS_SUBNORM, DBL_HAS_SUBNORM and LDBL_HAS_SUBNORM:

$-1$ indeterminable

$0$ absent (type does not support subnormal numbers)

$1$ present (type does support subnormal numbers)

Each of the signaling NaN macros

FLT_SNAN
DBL_SNAN
LDBL_SNAN

is defined if and only if the respective type contains signaling NaNs. They expand to a constant expression of the respective type representing a signaling NaN. If a signaling NaN macro, optionally preceded by the unary + or - operator, is used as an initializer that is evaluated at translation time to initialize an object of the same type, the object is initialized with a signaling NaN value.

The macro

INFINITY

is defined if and only if the implementation supports an infinity for the type float. It expands to a constant expression of type float representing positive or unsigned infinity.

The macro

NAN

is defined if and only if the implementation supports quiet NaNs for the float type. It expands to a constant expression of type float representing a quiet NaN.

The values given in the following list shall be replaced by constant expressions with implementationdefined values that are greater or equal in magnitude (absolute value) to those shown, with the same sign:

• radix of exponent representation, $b$

FLT_RADIX                        2

• number of base-FLT_RADIX digits in the floating-point significand, $p$

FLT_MANT_DIG
DBL_MANT_DIG
LDBL_MANT_DIG

• number of decimal digits, $n$, such that any floating-point number with $p$ radix $b$ digits can be rounded to a floating-point number with $n$ decimal digits and back again, using to-nearest rounding for both roundings, without change to the value, � $p{\log }_{10}b$ if $b$ is a power of $10$ $\lceil 1+p{\log }_{10}b\rceil$ otherwise

FLT_DECIMAL_DIG                   6
DBL_DECIMAL_DIG                  10
LDBL_DECIMAL_DIG                 10

• number of decimal digits, $n$, such that any floating-point number in the widest of the supported floating types and the supported ISO/IEC 60559 encodings with $p_{\max }$ radix $b$ digits can be rounded to a floating-point number with $n$ decimal digits and back again, using to-nearest rounding for both roundings, without change to the value, � $p_{\max }{\log }_{10}b$ if $b$ is a power of $10$ $\lceil 1+p_{\max }{\log }_{10}b\rceil$ otherwise

DECIMAL_DIG                     10
FLT_DIG                          6
DBL_DIG                         10
LDBL_DIG                        10
FLT_MIN_EXP
DBL_MIN_EXP
LDBL_MIN_EXP
FLT_MIN_10_EXP                 -37
DBL_MIN_10_EXP                 -37
LDBL_MIN_10_EXP                -37
FLT_MAX_EXP
DBL_MAX_EXP
LDBL_MAX_EXP
FLT_MAX_10_EXP                 +37
DBL_MAX_10_EXP                 +37
LDBL_MAX_10_EXP                +37

The values given in the following list shall be replaced by constant expressions with implementationdefined values that are greater than or equal to those shown:

• maximum representable finite floating-point number; if that number is normalized, its value is $(1-b^{-p})b^{e_{\max }}$

FLT_MAX                      1E+37
DBL_MAX                      1E+37
LDBL_MAX                     1E+37
FLT_NORM_MAX                 1E+37
DBL_NORM_MAX                 1E+37
LDBL_NORM_MAX                1E+37

The values given in the following list shall be replaced by constant expressions with implementationdefined (positive) values that are less than or equal to those shown:

• the difference between $1$ and the least normalized value greater than $1$ that is representable in the given floating type, $b^{1-p}$

FLT_EPSILON                   1E-5
DBL_EPSILON                   1E-9
LDBL_EPSILON                  1E-9

• minimum normalized positive floating-point number, $b^{e_{\min }-1}$

FLT_MIN                      1E-37
DBL_MIN                      1E-37
LDBL_MIN                     1E-37

• minimum positive floating-point number

FLT_TRUE_MIN                 1E-37
DBL_TRUE_MIN                 1E-37
LDBL_TRUE_MIN                1E-37

Conversion between real floating type and decimal character sequence with at most T_DECIMAL_DIG digits should be correctly rounded, where T is the macro prefix for the type. This assures conversion from real floating type to decimal character sequence with T_DECIMAL_DIG digits and back, using to-nearest rounding, is the identity function.

EXAMPLE 1 The following describes an artificial floating-point representation that meets the minimum requirements of this document, and the appropriate values in a <float.h> header for type float:

$x=s16e$ $6�$

$k=1$ $fk16-k$, $-31\le e\le +32$

FLT_RADIX                         16
FLT_MANT_DIG                       6
FLT_EPSILON          9.53674316E-07F
FLT_DECIMAL_DIG                    9
FLT_DIG                            6
FLT_MIN_EXP                      -31
FLT_MIN              2.93873588E-39F
FLT_MIN_10_EXP                   -38
FLT_MAX_EXP                      +32
FLT_MAX              3.40282347E+38F
FLT_MAX_10_EXP                   +38

EXAMPLE 2 The following describes floating-point representations that also meet the requirements for binary32 and binary64 numbers in ISO/IEC 60559,¹⁸⁾ and the appropriate values in a <float.h> header for types float and double. The decimal floating literals can possibly not give correct values (and hence are not appropriate values in a <float.h> header) if FLT_EVAL_METHOD is not 0 or if a translation-time rounding mode other

FLT_IS_IEC_60559                   1
FLT_RADIX                          2
FLT_MANT_DIG                      24
FLT_EPSILON          1.19209290E-07F // decimal floating literal
FLT_EPSILON                 0X1P-23F // hex floating literal
FLT_DECIMAL_DIG                    9
FLT_DIG                            6
FLT_MIN_EXP                     -125
FLT_MIN              1.17549435E-38F // decimal floating literal
FLT_MIN                    0X1P-126F // hex floating literal
FLT_TRUE_MIN         1.40129846E-45F // decimal floating literal
FLT_TRUE_MIN               0X1P-149F // hex floating literal
FLT_HAS_SUBNORM                    1
FLT_MIN_10_EXP                   -37
FLT_MAX_EXP                     +128
FLT_MAX              3.40282347E+38F // decimal floating literal
FLT_MAX              0X1.fffffeP127F // hex floating literal
FLT_MAX_10_EXP                   +38
DBL_MANT_DIG                      53
DBL_IS_IEC_60559                   1
DBL_EPSILON   2.2204460492503131E-16 // decimal floating literal
DBL_EPSILON                  0X1P-52 // hex floating literal
DBL_DECIMAL_DIG                   17
DBL_DIG                           15
DBL_MIN_EXP                    -1021
DBL_MIN      2.2250738585072014E-308 // decimal floating literal
DBL_MIN                    0X1P-1022 // hex floating literal
DBL_TRUE_MIN 4.9406564584124654E-324 // decimal floating literal
DBL_TRUE_MIN               0X1P-1074 // hex floating literal
DBL_HAS_SUBNORM                    1
DBL_MIN_10_EXP                  -307
DBL_MAX_EXP                    +1024
DBL_MAX      1.7976931348623157E+308 // decimal floating literal
DBL_MAX       0X1.fffffffffffffP1023 // hex floating literal
DBL_MAX_10_EXP                  +308

This subclause specifies macros in <float.h> that provide characteristics of decimal floating types (an optional feature) in terms of the model presented in 5.3.5.3.3. An implementation shall provide these macros if and only if it defines __STDC_IEC_60559_DFP__. The prefixes DEC32_, DEC64_, and DEC128_ denote the types _Decimal32, _Decimal64, and _Decimal128 respectively.

DEC_EVAL_METHOD is the decimal floating-point analog of FLT_EVAL_METHOD (5.3.5.3.3). Its implementation-defined value characterizes the use of evaluation formats for decimal floating types:

Each of the decimal signaling NaN macros

DEC32_SNAN
DEC64_SNAN
DEC128_SNAN

expands to a constant expression of the respective decimal floating type representing a signaling NaN. If an optional unary + or - operator followed by a signaling NaN macro is used for initializing an object of the same type that has static or thread storage duration, the object is initialized with a signaling NaN value.

The macro

DEC_INFINITY

expands to a constant expression of type _Decimal32 representing positive infinity.

The macro

DEC_NAN

expands to a constant expression of type _Decimal32 representing a quiet NaN.

The integer values given in the following lists shall be replaced by constant expressions suitable for use in conditional expression inclusion preprocessing directives:

• radix of exponent representation, $b$ (=10). For the standard floating types, this value is implementation-defined and is specified by the macro FLT_RADIX. For the decimal floating types there is no corresponding macro, because the value $10$ is an inherent property of the types. Wherever FLT_RADIX appears in a description of a function that has versions that operate on decimal floating types, it is noted that for the decimal floating-point versions the value used is implicitly $10$, rather than FLT_RADIX.
• number of digits in the coefficient

DEC32_MANT_DIG     7
DEC64_MANT_DIG     16
DEC128_MANT_DIG    34

• minimum exponent

DEC32_MIN_EXP      -94
DEC64_MIN_EXP      -382
DEC128_MIN_EXP     -6142

• maximum exponent

DEC32_MAX_EXP      97
DEC64_MAX_EXP      385
DEC128_MAX_EXP     6145
DEC32_MAX          9.999999E96DF
DEC64_MAX          9.999999999999999E384DD
DEC128_MAX         9.999999999999999999999999999999999E6144DL
DEC32_EPSILON      1E-6DF
DEC64_EPSILON      1E-15DD
DEC128_EPSILON     1E-33DL
DEC32_MIN          1E-95DF
DEC64_MIN          1E-383DD
DEC128_MIN         1E-6143DL
DEC32_TRUE_MIN     0.000001E-95DF
DEC64_TRUE_MIN     0.000000000000001E-383DD
DEC128_TRUE_MIN    0.000000000000000000000000000000001E-6143DL

For decimal floating-point arithmetic, it is often convenient to consider an alternate equivalent model where the significand is represented with integer rather than fraction digits. With $s$, $b$, $e$, $p$, and $f_k$ as defined in 5.3.5.3.3, a floating-point number $x$ is defined by the model:

$x=s·b^{(e-p)}$ $p$ �

$k=1$ $f_k·b^{(p-k)}$

With $b$ fixed to $10$, a decimal floating-point number $x$ is thus:

$x=s·{10}^{(e-p)}$ $p$ �

$k=1$ $f_k·{10}^{(p-k)}$

The quantum exponent is $q=e-p$ and the coefficient is $c=f_1{f}_2···f_p$, which is an integer between $0$ and ${10}^p-1$, inclusive. Thus, $x=s·c·{10}^q$ is represented by the triple of integers (s, c, q). The quantum of $x$ is ${10}^q$, which is the value of a unit in the last place of the coefficient. Table 5.1 shows the range of quantum exponents.

Table 5.1 — Quantum exponent ranges

Type _Decimal32 _Decimal64 _Decimal128 Maximum Quantum Exponent ($q_{\max }$ ) $90$ $369$ $6111$ Minimum Quantum Exponent ($q_{\min }$ ) $-101$ $-398$ $-6176$

Table 5.2 shows, for each operation delivering a result in decimal floating-point format, how the preferred quantum exponents of the operands, $Q($x), $Q($y), etc., determine the preferred quantum exponent of the operation result, provided the table formula is defined for the arguments. For the cases where the formula is undefined and the function result is $\pm \infty$, the preferred quantum exponent is immaterial because the quantum exponent of $\pm \infty$ is defined to be infinity. For the other cases where the formula is undefined and the function result is finite, the preferred quantum exponent is unspecified.

NOTE Although unspecified in ISO/IEC 60559, a preferred quantum exponent of 0 for the cases where the formula is undefined and the function result is finite would be a reasonable implementation choice.

Table 5.2 — Preferred quantum exponents

Operation Preferred quantum exponent of result roundeven, round, trunc, ceil, floor, rint, nearbyint

$max\left(Q\right($x$\left),0\right)$

nextup, nextdown, nextafter, nexttoward least possible fmin, fmax, fminimum, fmaximum, fminimum_mag, fmaximum_mag, fminimum_num, fmaximum_num, fminimum_mag_num, fmaximum_mag_num

$Q($x) if x gives the result, $Q($y) if y gives the result

scalbn, scalbln $Q($x) + n ldexp $Q($x) + p logb $0$ postfix ++ operator, postfix -- operator, prefix ++ operator, prefix -- operator

$min\left(Q\right($x$\left),0\right)$

+, d32add, d64add $min\left(Q\right($x$\left),Q\right($y)) -, d32sub, d64sub $min\left(Q\right($x$\left),Q\right($y))

*, d32mul, d64mul $Q($x$)+Q($y) /, d32div, d64div $Q($x$)-Q($y) sqrt, d32sqrt, d64sqrt $\lfloor Q($x$)/2\rfloor$ fma, d32fma, d64fma $min\left(Q\right($x$)+Q($y$\left),Q\right($z)) conversion from integer type $0$ exact conversion from non-decimal floating type

$0$

inexact conversion from non-decimal floating type

least possible

conversion between decimal floating types $Q($x)

*cx returned by canonicalize $Q($*x) strto, wcsto, scanf, floating literals of decimal floating type

see 7.25.2.7

-(x), +(x) $Q($x) fabs $Q($x) copysign $Q($x) quantize $Q($y) quantum $Q($x)

:

$Q($*xptr)

In the syntax notation used in this clause, syntactic categories (nonterminals) are indicated by italic type, and literal words and character set members (terminals) by bold type. A colon (:) following a nonterminal introduces its definition. Alternative definitions are listed on separate lines, except when prefaced by the words "one of". An optional symbol is indicated by the subscript "opt", so that

{ expression^opt }

indicates an optional expression enclosed in braces.

When syntactic categories are referred to in the main text, they are not italicized and words are separated by spaces instead of hyphens.

A summary of the language syntax is given in Annex A.

An identifier can denote:

• a standard attribute, an attribute prefix, or an attribute name;
• an object;
• a function;
• a tag or a member of a structure, union, or enumeration;
• a typedef name;
• a label name;
• a macro name;
• or, a macro parameter.

The same identifier can denote different entities at different points in the program. A member of an enumeration is called an enumeration constant. Macro names and macro parameters are not considered further here, because prior to the semantic phase of program translation any occurrences of macro names in the source file are replaced by the preprocessing token sequences that constitute their macro definitions.

For each different entity that an identifier designates, the identifier is visible (i.e. can be used) only within a region of program text called its scope. Different entities designated by the same identifier either have different scopes or are in different name spaces. There are four kinds of scopes: function, file, block, and function prototype. (A function prototype is a declaration of a function.)

A label name is the only kind of identifier that has function scope. It can be used (in a goto statement) anywhere in the function in which it appears, and is declared implicitly by its syntactic appearance (followed by a : and a statement).

Every other identifier has scope determined by the placement of its declaration (in a declarator or type specifier). If the declarator or type specifier that declares the identifier appears outside of any block or list of parameters, the identifier has file scope, which terminates at the end of the translation unit. If the declarator or type specifier that declares the identifier appears inside a block or within the list of parameter declarations in a function definition, the identifier has block scope, which terminates at the end of the associated block. If the declarator or type specifier that declares

Unless explicitly stated otherwise, where this document uses the term "identifier" to refer to an entity (as opposed to the syntactic construct), it refers to the entity in the relevant name space whose declaration is visible at the point the identifier occurs.

Two identifiers have the same scope if and only if their scopes terminate at the same point.

Structure, union, and enumeration tags have scope that begins just after the appearance of the tag in a type specifier that declares the tag. Each enumeration constant has scope that begins just after the appearance of its defining enumerator in an enumerator list. An ordinary identifier that has an underspecified definition has scope that starts when the definition is completed; if the same ordinary identifier declares another entity with a scope that encloses the current block, that declaration is hidden as soon as the inner declarator is completed.¹⁹⁾ Any other identifier has scope that begins just after the completion of its declarator.

As a special case, a type name (which is not a declaration of an identifier) is considered to have a scope that begins just after the place within the type name where the omitted identifier would appear were it not omitted. A compound literal (which is an expression that provides access to an anonymous object) is associated with the scope of the type name used in its definition; that scope is either file scope, function prototype scope, or block scope.

Forward references: declarations (6.7), function calls (6.5.3.3), function calls (6.5.3.6), function definitions (6.9.2), identifiers (6.4.3), macro replacement (6.10.5), name spaces of identifiers (6.2.3), source file inclusion (6.10.3), statements and blocks (6.8).

An identifier declared in different scopes or in the same scope more than once can be made to refer to the same object or function by a process called linkage.²⁰⁾ There are three kinds of linkage: external, internal, and none.

In the set of translation units and libraries that constitutes an entire program, each declaration of a particular identifier with external linkage denotes the same object or function. Within one translation unit, each declaration of an identifier with internal linkage denotes the same object or function. Each declaration of an identifier with no linkage denotes a unique entity.

If the declaration of a file scope identifier for:

• an object contains any of the storage-class specifiers static or constexpr;
• or, a function contains the storage-class specifier static,

then the identifier has internal linkage.²¹⁾

For an identifier declared with the storage-class specifier extern in a scope in which a prior declaration of that identifier is visible,²²⁾ if the prior declaration specifies internal or external linkage, the linkage of the identifier at the later declaration is the same as the linkage specified at the prior declaration. If no prior declaration is visible, or if the prior declaration specifies no linkage, then the identifier has external linkage.

If the declaration of an identifier for a function has no storage-class specifier, its linkage is determined exactly as if it were declared with the storage-class specifier extern. If the declaration of an identifier

The following identifiers have no linkage: an identifier declared to be anything other than an object or a function; an identifier declared to be a function parameter; a block scope identifier for an object declared without the storage-class specifier extern.

If more than one declaration of a particular identifier is visible at any point in a translation unit, the syntactic context disambiguates uses that refer to different entities. Thus, there are separate name spaces for various categories of identifiers, as follows:

• label names (disambiguated by the syntax of the label declaration and use);
• the tags of structures, unions, and enumerations (disambiguated by following any²³⁾ of the keywords struct, union, or enum);
• the members of structures or unions; each structure or union has a separate name space for its members (disambiguated by the type of the expression used to access the member via the . or -> operator);
• standard attributes and attribute prefixes (disambiguated by the syntax of the attribute specifier and name of the attribute token) (6.7.13);
• the trailing identifier in an attribute prefixed token; each attribute prefix has a separate name space for the implementation-defined attributes that it introduces (disambiguated by the attribute prefix and the trailing identifier token);
• all other identifiers, called ordinary identifiers (declared in ordinary declarators or as enumeration constants).

An object has a storage duration that determines its lifetime. There are four storage durations: static, thread, automatic, and allocated. Allocated storage is described in 7.25.4.

The lifetime of an object is the portion of program execution during which storage is guaranteed to be reserved for it. An object exists, has a constant address,²⁴⁾ and retains its last-stored value throughout its lifetime.²⁵⁾ If an object is referred to outside of its lifetime, the behavior is undefined. If a pointer value is used in an evaluation after the object the pointer points to (or just past) reaches the end of its lifetime, the behavior is undefined. The representation of a pointer object becomes indeterminate when the object the pointer points to (or just past) reaches the end of its lifetime.

An object whose identifier is declared without the storage-class specifier thread_local, and either with external or internal linkage or with the storage-class specifier static, has static storage duration. Its lifetime is the entire execution of the program and its stored value is initialized only once, prior to program startup.

An object whose identifier is declared with the storage-class specifier thread_local has thread storage duration. Its explicit or implicit initializer is evaluated prior to program execution, its lifetime is the entire execution of the thread for which it is created, and its stored value is initialized with the previously determined value when the thread is started. There is a distinct object per thread, and

An object whose identifier is declared with no linkage and without the storage-class specifier static has automatic storage duration, as do some compound literals. The result of attempting to indirectly access an object with automatic storage duration from a thread other than the one with which the object is associated is implementation-defined.

For such an object that has a known constant size, see 6.2.5, its lifetime extends from entry into the block with which it is associated until execution of that block ends in any way. (Entering an enclosed block or calling a function suspends, but does not end, execution of the current block.) If the block is entered recursively, a new instance of the object is created each time. The initial representation of the object is indeterminate. If an initialization is specified for the object and it is not specified with constexpr, it is performed each time the declaration or compound literal is reached in the execution of the block; if it is specified with constexpr the initializer is evaluated once at translation time and the new instance of the object is initialized to that fixed value each time the specification is reached; otherwise, the representation of the object becomes indeterminate each time the declaration is reached.

For such an object that does not have a known constant size, its lifetime extends from the declaration of the object until execution of the program leaves the scope of the declaration.²⁶⁾ If the scope is entered recursively, a new instance of the object is created each time. The initial representation of the object is indeterminate.

A non-lvalue expression with structure or union type, where the structure or union contains a member with array type (including, recursively, members of all contained structures and unions) refers to an object with automatic storage duration and temporary lifetime.²⁷⁾ Its lifetime begins when the expression is evaluated and its initial value is the value of the expression. Its lifetime ends when the evaluation of the containing full expression ends. Any attempt to modify an object with temporary lifetime results in undefined behavior. An object with temporary lifetime behaves as if it were declared with the type of its value for the purposes of effective type. Such an object may not have a unique address.

Forward references: array declarators (6.7.7.3), compound literals (6.5.3.6), declarators (6.7.7), function calls (6.5.3.3), initialization (6.7.11), statements (6.8), effective type (6.5.1).

The meaning of a value stored in an object or returned by a function is determined by the type of the expression used to access it. (An identifier declared to be an object is the simplest such expression; the type is specified in the declaration of the identifier.) Types are partitioned into object types (types that describe objects) and function types (types that describe functions). At various points within a translation unit an object type can be incomplete²⁸⁾ (lacking sufficient information to determine the size of objects of that type) or complete (having sufficient information).²⁹⁾

An object declared as type bool is large enough to store the values false and true.

An object declared as type char is large enough to store any member of the basic execution character set. If a member of the basic execution character set is stored in a char object, its value is guaranteed to be nonnegative. If any other character is stored in a char object, the resulting value is implementation-defined but shall be within the range of values that can be represented in that type.

There are five standard signed integer types, designated as signed char, short int, int, long int, and long long int. (These and other types can be designated in several additional ways, as

A bit-precise signed integer type is designated as _BitInt(N) where N is an integer constant expression that specifies the number of bits that are used to represent the type, including the sign bit. Each value of N designates a distinct type.³⁰⁾

There may also be implementation-defined extended signed integer types.³¹⁾ The standard signed integer types, bit-precise signed integer types, and extended signed integer types are collectively called signed integer types.³²⁾

An object declared as type signed char occupies the same amount of storage as a "plain" char object. A "plain" int object has the natural size suggested by the architecture of the execution environment (large enough to contain any value in the range INT_MIN to INT_MAX as defined in the header <limits.h>).

For each of the signed integer types, there is a corresponding (but different) unsigned integer type (designated with the keyword unsigned) that uses the same amount of storage (including sign information) and has the same alignment requirements. The type bool and the unsigned integer types that correspond to the standard signed integer types are the standard unsigned integer types. The unsigned integer types that correspond to the extended signed integer types are the extended unsigned integer types. In addition to the unsigned integer types that correspond to the bit-precise signed integer types there is the type unsigned _BitInt(1), which uses one bit to represent the type. Collectively, unsigned _BitInt(1) and the unsigned integer types that correspond to the bitprecise signed integer types are the bit-precise unsigned integer types. The standard unsigned integer types, bit-precise unsigned integer types, and extended unsigned integer types are collectively called unsigned integer types.³³⁾

The standard signed integer types and standard unsigned integer types are collectively called the standard integer types; the bit-precise signed integer types and bit-precise unsigned integer types are collectively called the bit-precise integer types; the extended signed integer types and extended unsigned integer types are collectively called the extended integer types.

For any two integer types with the same signedness and different integer conversion rank (see 6.3.2.1), the range of values of the type with smaller integer conversion rank is a subrange of the values of the other type.

The range of nonnegative values of a signed integer type is a subrange of the corresponding unsigned integer type, and the representation of the same value in each type is the same.³⁴⁾ The range of representable values for the unsigned type is $0$ to $2^N-1$ (inclusive). A computation involving unsigned operands can never produce an overflow, because arithmetic for the unsigned type is performed modulo $2^N$.

There are three standard floating types, designated as float, double, and long double.³⁵⁾ The set of values of the type float is a subset of the set of values of the type double; the set of values of the type double is a subset of the set of values of the type long double.

There are three decimal floating types, designated as _Decimal32, _Decimal64, and _Decimal128. Respectively, they have the ISO/IEC 60559 formats: decimal32,³⁶⁾ decimal64, and decimal128. (Decimal floating types are a conditional feature that implementations may not support; see 6.10.10.4.)

The standard floating types and the decimal floating types are collectively called the real floating types..

There are three complex types, designated as float _Complex, double _Complex, and long double _Complex. (Complex types are a conditional feature that implementations may not support; see 6.10.10.4.) The real floating and complex types are collectively called the floating types.

For each floating type there is a corresponding real type, which is always a real floating type. For real floating types, it is the same type. For complex types, it is the type given by deleting the keyword _Complex from the type name.

Each complex type has the same representation and alignment requirements as an array type containing exactly two elements of the corresponding real type; the first element is equal to the real part, and the second element to the imaginary part, of the complex number. In this document complex values are sometimes written in the form $x+\mathrm{iy}$, where $x$ and $y$ are the values of the real and imaginary parts, and $i$ represents the mathematical imaginary unit, which has the property $i^2=-1$. The form $x-\mathrm{iy}$ is equivalent to $x+i(-y)$.

The type char, the signed and unsigned integer types, and the floating types are collectively called the basic types. The basic types are complete object types. Even if the implementation defines two or more basic types to have the same representation, they are nevertheless distinct types.

NOTE An implementation can define new keywords that provide alternative ways to designate a basic (or any other) type; this does not violate the requirement that all basic types be different. Implementation-defined keywords have the form of an identifier reserved for any use as described in 7.1.3.

The three types char, signed char, and unsigned char are collectively called the character types. The implementation shall define char to have the same range, representation, and behavior as either signed char or unsigned char.³⁷⁾

An enumeration comprises a set of named constants of integer type. Each distinct enumeration constitutes a different enumerated type.

The type char, the signed and unsigned integer types, and the enumerated types are collectively called integer types. The integer and real floating types are collectively called real types.

Integer and floating types are collectively called arithmetic types. Each arithmetic type belongs to one type domain: the real type domain comprises the real types, the complex type domain comprises the complex types.

The void type comprises an empty set of values; it is an incomplete object type that cannot be completed.

Any number of derived types can be constructed from the object and function types, as follows:

• An array type describes a contiguously allocated nonempty set of objects with a particular member object type, called the element type. The element type shall be complete whenever the array type is specified. Array types are characterized by their element type and by the number of elements in the array. An array type is said to be derived from its element type, and if its element type is T, the array type is sometimes called "array of T". The construction of an array type from an element type is called "array type derivation".
• A structure type describes a sequentially allocated nonempty set of member objects (and, in certain circumstances, an incomplete array), each of which has an optionally specified name and possibly distinct type.
• A union type describes an overlapping nonempty set of member objects, each of which has an optionally specified name and possibly distinct type.
• A function type describes a function with specified return type. A function type is characterized by its return type and the number and types of its parameters. A function type is said to be derived from its return type, and if its return type is T, the function type is sometimes called "function returning T". The construction of a function type from a return type is called "function type derivation".

The type of the nullptr constant, i.e. nullptr_t, is an unqualified complete scalar type that is different from all pointer or arithmetic types and is neither an atomic or array type and has exactly one value, nullptr.

Arithmetic types, pointer types, and the nullptr_t type are collectively called scalar types. Array and structure types are collectively called aggregate types.³⁸⁾

An array type of unknown size is an incomplete type. It is completed, for an identifier of that type, by specifying the size in a later declaration (with internal or external linkage). A structure or union type of unknown content (as described in 6.7.3.4) is an incomplete type. It is completed, for all declarations of that type, by declaring the same structure or union tag with its defining content later in the same scope.

A complete type shall have a size that is less than or equal to SIZE_MAX. A type has known constant size if it is complete and is not a variable length array type.³⁹⁾

Array, function, and pointer types are collectively called derived declarator types. A declarator type derivation from a type T is the construction of a derived declarator type from T by the application of an array-type, a function-type, or a pointer-type derivation to T.

A type is characterized by its type category, which is either the outermost derivation of a derived type (as noted previously in this subclause in the construction of derived types), or the type itself if the type consists of no derived types.

Any type so far mentioned is an unqualified type. Each unqualified type has several qualified versions of its type,⁴⁰⁾ corresponding to the combinations of one, two, or all three of the const, volatile, and restrict qualifiers. The qualified or unqualified versions of a type are distinct types that belong to the same type category and have the same representation and alignment requirements.⁴¹⁾ An array and its element type are always considered to be identically qualified.⁴²⁾ Any other derived type is not qualified by the qualifiers (if any) of the type from which it is derived.

Further, there is the _Atomic qualifier. The presence of the _Atomic qualifier designates an atomic type. The size, representation, and alignment of an atomic type may not be the same as those of the corresponding unqualified type. Therefore, this document explicitly uses the phrase "atomic, qualified, or unqualified type" whenever the atomic version of a type is permitted along with the other qualified versions of a type. The phrase "qualified or unqualified type", without specific mention of atomic, does not include the atomic types.

EXAMPLE 1 The type designated as "float *" has type "pointer to float". Its type category is pointer, not a floating type. The const-qualified version of this type is designated as "float * const" whereas the type designated as "const float *" is not a qualified type — its type is "pointer to const-qualified float" and is a pointer to a qualified type.

EXAMPLE 2 The type designated as "struct tag (*[5])(float)" has type "array of pointer to function returning struct tag". The array has length five and the function has a single parameter of type float. Its type category is array.

The representations of all types are unspecified except as stated in this subclause.

Except for bit-fields, objects are composed of contiguous sequences of one or more bytes, the number, order, and encoding of which are either explicitly specified or implementation-defined.

Values stored in unsigned bit-fields and objects of type unsigned char shall be represented using a pure binary notation.

Values stored in non-bit-field objects of any other object type are represented using $n\times$CHAR_BIT bits, where $n$ is the size of an object of that type, in bytes. An object that has the value can be copied into an object of type unsigned char [$n$] (e.g. by memcpy); the resulting set of bytes is called the object representation of the value. Values stored in bit-fields consist of $m$ bits, where $m$ is the size specified for the bit-field. The object representation is the set of $m$ bits the bit-field comprises in the addressable storage unit holding it. Two values (other than NaNs) with the same object representation compare equal, but values that compare equal may have different object representations.

Certain object representations do not represent a value of the object type. If such a representation is read by an lvalue expression that does not have character type, the behavior is undefined. If such a representation is produced by a side effect that modifies all or any part of the object by an lvalue expression that does not have character type, the behavior is undefined.⁴³⁾ Such a representation is called a non-value representation.

When a value is stored in an object of structure or union type, including in a member object, the bytes of the object representation that correspond to any padding bytes take unspecified values (e.g. structure and union assignment can fail to copy any padding bits). The object representation of a structure or union object is never a non-value representation, even though the byte range corresponding to a member of the structure or union object can be a non-value representation for that member.

When a value is stored in a member of an object of union type, the bytes of the object representation that do not correspond to that member but do correspond to other members take unspecified values.

Where an operator is applied to a value that has more than one object representation, which object representation is used shall not affect the value of the result.⁴⁴⁾ Where a value is stored in an object using a type that has more than one object representation for that value, it is unspecified which representation is used, but a non-value representation shall not be generated.

Loads and stores of objects with atomic types are done with memory_order_seq_cst semantics.

For unsigned integer types the bits of the object representation shall be divided into two groups: value bits and padding bits. If there are $N$ value bits, each bit shall represent a different power of $2$ between $1$ and $2^{N-1}$, so that objects of that type shall be capable of representing values from $0$ to $2^N-1$ using a pure binary representation; this shall be known as the value representation. The values of any padding bits are unspecified. The number of value bits $N$ is called the width of the

For signed integer types, the bits of the object representation shall be divided into three groups: value bits, padding bits, and the sign bit. If the corresponding unsigned type has width $N$, the signed type uses the same number of $N$ bits, its width, as value bits and sign bit. $N-1$ are value bits and the remaining bit is the sign bit. Each bit that is a value bit shall have the same value as the same bit in the object representation of the corresponding unsigned type. If the sign bit is zero, it shall not affect the resulting value. If the sign bit is one, it has value $-\left(2^{N-1}\right)$. There can be padding bits; signed char shall not have any padding bits.

The values of any padding bits are unspecified. A valid object representation of a signed integer type where the sign bit is zero is a valid object representation of the corresponding unsigned type, and shall represent the same value. For any integer type, the object representation where all the bits are zero shall be a representation of the value zero in that type.

The precision of an integer type is the number of value bits.

NOTE 1 Some combinations of padding bits can generate non-value representations, for example, if one padding bit is a parity bit. Regardless, no arithmetic operation on valid values can generate a non-value representation other than as part of an exceptional condition such as an integer overflow. All other combinations of padding bits are alternative object representations of the value specified by the value bits.

NOTE 2 The sign representation defined in this document is called two’s complement. Previous editions of this document (specifically ISO/IEC 9899:2018 and prior editions) additionally allowed other sign representations.

NOTE 3 For unsigned integer types the width and precision are the same, while for signed integer types the width is one greater than the precision.

A pointer to void shall have the same representation and alignment requirements as a pointer to a character type.⁴¹⁾ Similarly, pointers to qualified or unqualified versions of compatible types shall have the same representation and alignment requirements. All pointers to structure types shall have the same representation and alignment requirements as each other. All pointers to union types shall have the same representation and alignment requirements as each other. Pointers to other types may not have the same representation or alignment requirements.

The size and alignment of nullptr_t is the same as for a pointer to character type. An object representation of the value of nullptr is the same as the object representation of a null pointer value of type void*. All other object representations are non-value representations for this type.

Two types are compatible types if they are the same. Additional rules for determining whether two types are compatible are described in 6.7.3 for type specifiers, in 6.7.4 for type qualifiers, and in 6.7.7 for declarators.⁴⁵⁾ Moreover, two complete structure, union, or enumerated types declared with the same tag are compatible if members satisfy the following requirements:

• there shall be a one-to-one correspondence between their members such that each pair of corresponding members are declared with compatible types;
• if one member of the pair is declared with an alignment specifier, the other is declared with an equivalent alignment specifier;
• and, if one member of the pair is declared with a name, the other is declared with the same name.

For two structures, corresponding members shall be declared in the same order. For two unions declared in the same translation unit, corresponding members shall be declared in the same order. For two structures or unions, corresponding bit-fields shall have the same widths. For two enumerations,

All declarations that refer to the same object or function shall have compatible type; otherwise, the behavior is undefined.

A composite type can be constructed from two types that are compatible. If both types are the same type, the composite type is this type. Otherwise, it is a type that is compatible with both and satisfies the following conditions:

• If both types are structure types or both types are union types, the composite type is determined recursively by forming the composite types of their members.
• If both types are array types, the following rules are applied:

• If one type is an array of known constant length, the composite type is an array of that length.

• Otherwise, if one type is a variable length array whose length is specified, the composite type is a variable length array of that length.

• Otherwise, if one type is a variable length array of unspecified length, the composite type is a variable length array of unspecified length.

• Otherwise, both types are arrays of unknown length, and the composite type is an array of unknown length.

The element type of the composite type is the composite type of the two element types.

• If both types are function types, the type of each parameter in the composite parameter type list is the composite type of the corresponding parameters.
• If one of the types has a standard attribute, the composite type also has that attribute.
• If both types are enumerated types, the composite type is an enumerated type.
• If one type is an enumerated type and the other is an integer type other than an enumerated type, it is implementation-defined whether or not the composite type is an enumerated type.

These rules apply recursively to the types from which the two types are derived.

EXAMPLE 1 Given an object nsize of type size_t and two types:

• double[3] and double[] have a composite type of double[3]
• double[] and double[nsize] have a composite type of double[nsize]
• double[] and double[*] have a composite type of double[*]

If any of the original types satisfies all requirements of the composite type, it is unspecified whether the composite type is one of these types or a different type that satisfies the requirements.⁴⁷⁾

For an identifier with internal or external linkage declared in a scope in which a prior declaration of that identifier is visible,⁴⁸⁾ if the prior declaration specifies internal or external linkage, the type of the identifier at the later declaration becomes the composite type.

EXAMPLE 2 Given the following two file scope declarations:

int f(int (*)(char *), double (*)[3]);
int f(int (*)(char *), double (*)[]);

int f(int (*)(char *), double (*)[3]);

Complete object types have alignment requirements which place restrictions on the addresses at which objects of that type can be allocated. An alignment is an implementation-defined integer value representing the number of bytes between successive addresses at which a given object can be allocated. An object type imposes an alignment requirement on every object of that type: stricter alignment can be requested using the alignas keyword.

A fundamental alignment is a valid alignment less than or equal to alignof(max_align_t). Fundamental alignments shall be supported by the implementation for objects of all storage durations. The alignment requirements of the following types shall be fundamental alignments:

• all qualified or unqualified basic types;
• all qualified or unqualified enumerated types;
• all qualified or unqualified pointer types;
• all array types whose element type has a fundamental alignment requirement;
• all types specified in Clause 7 as complete object types;
• all structure or union types whose elements have types with fundamental alignment requirements and none of whose elements have an alignment specifier specifying an alignment that is not a fundamental alignment.

Whether any atomic types have fundamental alignment is implementation-defined.

An extended alignment is represented by an alignment greater than alignof(max_align_t). It is implementation-defined whether any extended alignments are supported and the storage durations for which they are supported. A type having an extended alignment requirement is an over-aligned type.⁴⁹⁾

Alignments are represented as values of the type size_t. Valid alignments include only fundamental alignments, plus an additional implementation-defined set of values, which can be empty. Every valid alignment value shall be a nonnegative integral power of two.

Alignments have an order from weaker to stronger or stricter alignments. Stricter alignments have larger alignment values. An address that satisfies an alignment requirement also satisfies any weaker valid alignment requirement.

The alignment requirement of a complete type can be queried using an alignof expression. The types char, signed char, and unsigned char shall have the weakest alignment requirement.

Comparing alignments is meaningful and provides the obvious results:

• Two alignments are equal when their numeric values are equal.
• Two alignments are different when their numeric values are not equal.
• When an alignment is larger than another it represents a stricter alignment.

The literal encoding is an implementation-defined mapping of the characters of the execution character set to the values in a character literal (6.4.5.5) or string literal (6.4.6). It shall support a mapping from all the basic execution character set values into the implementation-defined encoding. It can contain multibyte character sequences (5.3.2).

The wide literal encoding is an implementation-defined mapping of the characters of the execution character set to the values in a wchar_t character literal (6.4.5.5) or a wchar_t string literal (6.4.6). It shall support a mapping from all the basic execution character set values into the implementationdefined encoding. The mapping shall produce values identical to the literal encoding for all the basic execution character set values if an implementation does not define __STDC_MB_MIGHT_NEQ_WC__. One or more values may map to one or more values of the extended execution character set.

A code unit is a single compositional unit of encoded information, usually of type char, wchar_t, char8_t, char16_t, or char32_t.

A code point is a single compositional unit of decoded information. Code points are generally used as the single complete decoded output, or as an intermediary to transcode to other code units. A Unicode code point is a single compositional unit of decoded information as defined in ISO/IEC 10646, typically used to convert to or from UTF-8, UTF-16, and UTF-32.

The narrow execution encoding is the implementation-defined, LC_CTYPE-influenced (7.11.1), localebased execution environment encoding. The wide execution encoding is the implementation-defined, LC_CTYPE-influenced, locale-based wide execution environment encoding. Both of these encodings are called the execution encodings.

An unrecorded encoding error occurs when an encoding, decoding, or transcoding function encounters an input sequence of code units or code points that

• does not form a valid sequence according to the encoding being associated with the sequence
• or, is not representable in the output encoding or coded character set.

An encoding error is the same as an unrecorded encoding error, except that the value of the macro EILSEQ (7.5) is stored in errno when such an error occurs during execution of the functions defined in this document unless otherwise specified.

Several operators convert operand values from one type to another automatically. This subclause specifies the result required from such an implicit conversion, as well as those that result from a cast operation (an explicit conversion). The list in 6.3.2.8 summarizes the conversions performed by most ordinary operators; it is supplemented as required by the discussion of each operator in 6.5.1.

Unless explicitly stated otherwise, conversion of an operand value to a compatible type causes no change to the value or the representation.

Every integer type has an integer conversion rank defined as follows:

• No two signed integer types shall have the same rank, even if they have the same representation.
• The rank of a signed integer type shall be greater than the rank of any signed integer type with less precision.
• The rank of long long int shall be greater than the rank of long int, which shall be greater than the rank of int, which shall be greater than the rank of short int, which shall be greater than the rank of signed char.
• The rank of a bit-precise signed integer type shall be greater than the rank of any standard integer type with less width or any bit-precise integer type with less width.
• The rank of any unsigned integer type shall equal the rank of the corresponding signed integer type, if any.
• The rank of any standard integer type shall be greater than the rank of any extended integer type with the same width or bit-precise integer type with the same width.
• The rank of any bit-precise integer type relative to an extended integer type of the same width is implementation-defined.
• The rank of char shall equal the rank of signed char and unsigned char.
• The rank of bool shall be less than the rank of all other standard integer types.
• The rank of any enumerated type shall equal the rank of the compatible integer type (see 6.7.3.3).
• The rank of any extended signed integer type relative to another extended signed integer type with the same precision is implementation-defined, but still subject to the other rules for determining the integer conversion rank.
• For all integer types T1, T2, and T3, if T1 has greater rank than T2 and T2 has greater rank than

T3, then T1 has greater rank than T3.

The following can be used in an expression wherever an int or unsigned int can be used:

• An object or expression with an integer type (other than int or unsigned int) whose integer conversion rank is less than or equal to the rank of int and unsigned int.
• A bit-field of type bool, int, signed int, or unsigned int.

The value from a bit-field of a bit-precise integer type is converted to the corresponding bit-precise integer type. If the original type is not a bit-precise integer type (6.2.5): if an int can represent all values of the original type (as restricted by the width, for a bit-field), the value is converted to an int;⁵⁰⁾ otherwise, it is converted to an unsigned int. These are called the integer promotions. All other types are unchanged by the integer promotions.

NOTE The integer promotions are applied only:

1. as part of the usual arithmetic conversions,
2. to certain argument expressions,
3. to the operands of the unary +, -, and ~ operators,
4. and to both operands of the shift operators,

The integer promotions preserve value including sign. As discussed earlier, whether a "plain" char can hold negative values is implementation-defined.

When any scalar value is converted to bool, the result is false if the value is a zero (for arithmetic types), null (for pointer types), or the scalar has type nullptr_t; otherwise, the result is true.

When a value with integer type is converted to another integer type other than bool, if the value can be represented by the new type, it is unchanged.

Otherwise, if the new type is unsigned, the value is converted by repeatedly adding or subtracting one more than the maximum value that can be represented in the new type until the value is in the range of the new type.⁵¹⁾

Otherwise, the new type is signed and the value cannot be represented in it; either the result is implementation-defined or an implementation-defined signal is raised.

When a finite value of standard floating type is converted to an integer type other than bool, the fractional part is discarded (i.e. the value is truncated toward zero). If the value of the integral part cannot be represented by the integer type, the behavior is undefined.⁵²⁾

When a finite value of decimal floating type is converted to an integer type other than bool, the fractional part is discarded (i.e. the value is truncated toward zero). If the value of the integral part cannot be represented by the integer type, the "invalid" floating-point exception shall be raised and the result of the conversion is unspecified.

When a value of integer type is converted to a standard floating type, if the value being converted can be represented exactly in the new type, it is unchanged. If the value being converted is in the range of values that can be represented but cannot be represented exactly, the result is either the nearest higher or nearest lower representable value, chosen in an implementation-defined manner. If the value being converted is outside the range of values that can be represented, the behavior is undefined. Results of some implicit conversions can be represented in greater range and precision than that required by the new type (see 6.3.2.8 and 6.8.7.5).

When a value of integer type is converted to a decimal floating type, if the value being converted can be represented exactly in the new type, it is unchanged. If the value being converted cannot be represented exactly, the result shall be correctly rounded with exceptions raised as specified in ISO/IEC 60559.

When a value of real floating type is converted to a real floating type, if the value being converted can be represented exactly in the new type, it is unchanged.

When a value of real floating type is converted to a standard floating type, if the value being converted is in the range of values that can be represented but cannot be represented exactly, the result is either the nearest higher or nearest lower representable value, chosen in an implementationdefined manner. If the value being converted is outside the range of values that can be represented, the behavior is undefined.

When a value of real floating type is converted to a decimal floating type, if the value being converted cannot be represented exactly, the result is correctly rounded with exceptions raised as specified in ISO/IEC 60559.

Results of some implicit conversions may be represented in greater range and precision than that required by the new type (see 6.3.2.8 and 6.8.7.5).

When a value of complex type is converted to another complex type, both the real and imaginary parts follow the conversion rules for the corresponding real types.

When a value of real type is converted to a complex type, the real part of the complex result value is determined by the rules of conversion to the corresponding real type and the imaginary part of the complex result value is a positive zero or an unsigned zero.

When a value of complex type is converted to a real type other than bool,⁵³⁾ the imaginary part of the complex value is discarded and the value of the real part is converted according to the conversion rules for the corresponding real type.

Many operators that expect operands of arithmetic type cause conversions and yield result types in a similar way. The purpose is to determine a common real type for the operands and result. For the specified operands, each operand is converted, without change of type domain, to a type whose corresponding real type is the common real type. Unless explicitly stated otherwise, the common real type is also the corresponding real type of the result, whose type domain is the type domain of the operands if they are the same, and complex otherwise. This pattern is called the usual arithmetic conversions:

If one operand has decimal floating type, the other operand shall not have standard floating, or complex type.

First, if the type of either operand is _Decimal128, the other operand is converted to _Decimal128.

Otherwise, if the type of either operand is _Decimal64, the other operand is converted to _Decimal64.

Otherwise, if the type of either operand is _Decimal32, the other operand is converted to _Decimal32.

Otherwise, if the corresponding real type of either operand is long double, the other operand is converted, without change of type domain, to a type whose corresponding real type is long double.

Otherwise, if the corresponding real type of either operand is double, the other operand is converted, without change of type domain, to a type whose corresponding real type is double.

Otherwise, if the corresponding real type of either operand is float, the other operand is converted, without change of type domain, to a type whose corresponding real type is float.⁵⁴⁾

Otherwise, if any of the two types is an enumeration, it is converted to its underlying type. Then, the integer promotions are performed on both operands. Next, the following rules are applied to the promoted operands:

If both operands have the same type, then no further conversion is needed.

The values of floating operands and of the results of floating expressions may be represented in greater range and precision than that required by the type; the types are not changed thereby. See 5.3.5.3.3 regarding evaluation formats.

EXAMPLE One consequence of _BitInt being exempt from the integer promotion rules (6.3.2) is that a _BitInt operand of a binary operator is not always promoted to an int or unsigned int as part of the usual arithmetic conversions. Instead, a lower-ranked operand is converted to the higher-rank operand type and the result of the operation is the higher-ranked type.

_BitInt(2) a2 = 1;
_BitInt(3) a3 = 2;
_BitInt(33) a33 = 1;
signed char c = 3;
a2 * a3; /* As part of the multiplication, a2 is converted to
            _BitInt(3) and the result type is _BitInt(3). */
a2 * c;  /* As part of the multiplication, c is promoted to int,
            a2 is converted to int and the result type is int. */
a33 * c; /* As part of the multiplication, c is promoted to int.
            Then, provided int has a width of at most 32,
            it is converted to _BitInt(33) and the result type
            is _BitInt(33). */
void func(_BitInt(8) a8, _BitInt(24) a24) {
      /* Cast one of the operands to 32-bits to guarantee the
         result of the multiplication can contain all possible values. */
      _BitInt(32) a32 = a8 * (_BitInt(32))a24;
}

An lvalue is an expression (with an object type other than void) that potentially designates an object;⁵⁵⁾ if an lvalue does not designate an object when it is evaluated, the behavior is undefined. When an object is said to have a particular type, the type is specified by the lvalue used to designate the object. A modifiable lvalue is an lvalue that does not have array type, does not have an incomplete type, does not have a const-qualified type, and if it is a structure or union, does not have any member (including, recursively, any member or element of all contained aggregates or unions) with a const-qualified type.

Except when it is the operand of:

An expression that has type "array of type" is converted to an expression with type "pointer to type" except when it is an operand of the sizeof operator, the _Countof operator, the typeof operators, the unary & operator, the array subscripting operator, or if it is a string literal used to initialize an array. The resulting pointer points to the initial element of the array object and is not an lvalue. If the array object has register storage class, the behavior is implementation-defined.

A function designator is an expression that has function type. Except when it is the operand of the sizeof operator,⁵⁶⁾ a typeof operator, or the unary & operator, a function designator with type "function returning type" is converted to an expression that has type "pointer to function returning type".

Forward references: address and indirection operators (6.5.4.3), assignment operators (6.5.17), common definitions <stddef.h> (7.22), initialization (6.7.11), postfix increment and decrement operators (6.5.3.5), prefix increment and decrement operators (6.5.4.2), the sizeof, _Countof, and alignof operators (6.5.4.5), structure and union members (6.5.3.4).

An expression that has type void is a void expression. If an expression of any other type is evaluated as a void expression, its value or designator is discarded. (A void expression is evaluated for its side effects.)

A pointer to void can be converted to or from a pointer to any object type. A pointer to any object type can be converted to a pointer to void and back again; the result shall compare equal to the original pointer.

For any qualifier q, a pointer to a non-q-qualified type can be converted to a pointer to the q-qualified version of the type; the values stored in the original and converted pointers shall compare equal.

An integer constant expression with the value $0$, such an expression cast to type void *, or the predefined constant nullptr is called a null pointer constant.⁵⁷⁾ If a null pointer constant or a value of the type nullptr_t (which is necessarily the value nullptr) is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function.

Conversion of a null pointer to another pointer type yields a null pointer of that type. Any two null pointers shall compare equal.

An integer can be converted to any pointer type. Except as previously specified, the result is implementation-defined, possibly not correctly aligned, can possibly not point to an entity of the referenced type, and can produce an indeterminate representation when stored into an object.⁵⁸⁾

Any pointer type can be converted to an integer type. Except as previously specified, the result is implementation-defined. If the result cannot be represented in the integer type, the behavior is undefined. The result is not required to be in the range of values of any integer type.

A pointer to an object type can be converted to a pointer to a different object type. If the resulting pointer is not correctly aligned⁵⁹⁾ for the referenced type, the behavior is undefined. Otherwise, when converted back again, the result shall compare equal to the original pointer. When a pointer to an object is converted to a pointer to a character type, the result points to the lowest addressed byte of the object. Successive increments of the result, up to the size of the object, yield pointers to the remaining bytes of the object.

A pointer to a function of one type can be converted to a pointer to a function of another type and back again; the result shall compare equal to the original pointer. If a converted pointer is used to call a function whose type is not compatible with the referenced type, the behavior is undefined.

The type nullptr_t can be converted to void, bool or to a pointer type; the result is a void expression, false, or a null pointer value, respectively.

A null pointer constant or value of type nullptr_t can be converted to nullptr_t.

Forward references: cast operators (6.5.5), equality operators (6.5.10), integer types capable of holding object pointers (7.23.2.5), simple assignment (6.5.17.2), the nullptr_t type (7.22.3).

token:

keyword

identifier

constant

string-literal

punctuator

preprocessing-token:

header-name

identifier

pp-number

character-literal

string-literal

punctuator

each universal character name that cannot be one of the above

each non-white-space character that cannot be one of the above

Each preprocessing token that is converted to a token shall have the lexical form of a keyword, an identifier, a constant, a string literal, or a punctuator. A single universal character name shall match one of the other preprocessing token categories.

A token is the minimal lexical element of the language in translation phases 7 and 8 (5.2.1.2). The categories of tokens are: keywords, identifiers, constants, string literals, and punctuators. A preprocessing token is the minimal lexical element of the language in translation phases 3 through 6. The categories of preprocessing tokens are: header names, identifiers, preprocessing numbers, character literals, string literals, punctuators, and both single universal character names as well as single non-white-space characters that do not lexically match the other preprocessing token categories.⁶⁰⁾ If a ’ or a " character matches the last category, the behavior is undefined. Preprocessing tokens can be separated by white space; this consists of comments (described later), or white-space characters (space, horizontal tab, new-line, vertical tab, and form-feed), or both. As described in 6.10, in certain circumstances during translation phase 4, white space (or the absence thereof) serves as more than preprocessing token separation. White space may appear within a preprocessing token only as part of a header name or between the quotation characters in a character literal or string literal.

If the input stream has been parsed into preprocessing tokens up to a given character, the next preprocessing token is the longest sequence of characters that could constitute a preprocessing token. There is one exception to this rule: header name preprocessing tokens are recognized only within #include and #embed preprocessing directives, in __has_include and __has_embed expressions, as well as in implementation-defined locations within #pragma directives. In such contexts, a sequence of characters that could be either a header name or a string literal is recognized as the former.

EXAMPLE 1 The program fragment 1Ex is parsed as a preprocessing number token (one that is not a valid floating or integer literal), even though a parse as the pair of preprocessing tokens 1 and Ex can produce a valid expression (for example, if Ex were a macro defined as +1). Similarly, the program fragment 1E1 is parsed as a preprocessing number (one that is a valid floating literal), whether or not E is a macro name.

EXAMPLE 2 The program fragment x+++++y is parsed as x ++ ++ + y, which violates a constraint on increment operators, even though the parse x ++ + ++ y can yield a correct expression.

keyword: one of

alignas alignof auto bool break case char const constexpr continue default

do double else enum extern false float for goto if inline

int long nullptr register restrict return short signed sizeof static static_assert

struct switch thread_local true typedef typeof typeof_unqual union unsigned void volatile

while _Atomic _BitInt _Complex _Countof _Decimal128 _Decimal32 _Decimal64 _Generic _Noreturn

The previously listed tokens (case sensitive) are reserved (in translation phases 7 and 8) for use as keywords except in an attribute token, and shall not be used otherwise.

Table 6.1 provides alternate spellings for certain keywords. These can be used wherever the keyword can.⁶¹⁾

Table 6.1 — Keywords and their spellings

Keyword Alternative Spelling alignas _Alignas alignof _Alignof bool _Bool static_assert _Static_assert thread_local _Thread_local

The spelling of these keywords, their alternate forms, and of false and true inside expressions that are subject to the # and ## preprocessing operators is unspecified.⁶²⁾

identifier:

identifier-start

identifier identifier-continue

identifier-start:

nondigit

XID_Start character

universal character name of class XID_Start

identifier-continue:

digit

nondigit

XID_Continue character

universal character name of class XID_Continue

nondigit: one of

_ a b c d e f g h i j k l m

n o p q r s t u v w x y z

A B C D E F G H I J K L M

N O P Q R S T U V W X Y Z

digit: one of

0 1 2 3 4 5 6 7 8 9

An XID_Start character is an implementation-defined character whose corresponding code point in ISO/IEC 10646 has the XID_Start property. An XID_Continue character is an implementationdefined character whose corresponding code point in ISO/IEC 10646 has the XID_Continue property. An identifier is a sequence of one identifier start character followed by 0 or more identifier continue characters, which designates one or more entities as described in 6.2.1. It is implementation-defined if a $ (U+0024, DOLLAR SIGN) may be used as a nondigit character. Lowercase and uppercase letters are distinct. There is no specific limit on the maximum length of an identifier.

The character classes XID_Start and XID_Continue are Derived Core Properties as described by UAX #44.⁶³⁾ Each character and universal character name in an identifier shall designate a character whose encoding in ISO/IEC 10646 has the XID_Continue property. The initial character (which can be a universal character name) shall designate a character whose encoding in ISO/IEC 10646 has the XID_Start property. An identifier shall conform to Normalization Form C as specified in ISO/IEC 10646. Annex D provides an overview of the conforming identifiers.

NOTE 1 Uppercase and lowercase letters are considered different for all identifiers.

NOTE 2 In translation phase 4, the term identifier also includes those preprocessing tokens (6.4.9) differentiated as keywords (6.4.2) in the later translation phase 7 (5.2.1.2).

When preprocessing tokens are converted to tokens during translation phase 7, if a preprocessing token could be converted to either a keyword or an identifier, it is converted to a keyword except in an attribute token.

Some identifiers are reserved.

If the program declares or defines an identifier in a context in which it is reserved (other than as allowed by 7.1.4), the behavior is undefined.

If the program defines a reserved identifier or standard attribute token described in 6.7.13.2 as a macro name, or removes (with #undef) any macro definition of an identifier in the first group listed previously or standard attribute token described in 6.7.13.2, the behavior is undefined.

Some identifiers may be potentially reserved. A potentially reserved identifier is an identifier which is not reserved unless made so by an implementation providing the identifier (7.1.3) but is anticipated to become reserved by an implementation or a future version of this document. An identifier that this document describes as optional:

• If it is defined as a macro it is reserved.
• Otherwise, if the definition is given in clauses 1 to 6 it is reserved.
• Otherwise, it is potentially reserved.

Implementations are encouraged to issue a diagnostic message when a potentially reserved identifier is declared or defined for any use that is not implementation-compatible (see subsequent description in this subclause) in a context where the potentially reserved identifier may be reserved under a conforming implementation. This brings attention to a potential conflict when porting a program to a future edition of this document.

An implementation-compatible use of a potentially reserved identifier is a declaration of an external name where the name is provided by the implementation as an external name and where the declaration declares an object or function with a type that is compatible with the type of the object or function provided by the implementation under that name.

As discussed in 5.3.5.2, an implementation may limit the number of significant initial characters in an identifier; the limit for an external name (an identifier that has external linkage) may be more restrictive than that for an internal name (a macro name or an identifier that does not have external linkage). The number of significant characters in an identifier is implementation-defined.

Any identifiers that differ in a significant character are different identifiers. If two identifiers differ only in nonsignificant characters, the behavior is undefined.

The identifier __func__ shall be implicitly declared by the translator as if, immediately following the opening brace of each function definition, the declaration

static const char __func__[] = "function-name " ;

This name is encoded as if the implicit declaration had been written in the source character set and then translated into the execution character set as indicated in translation phase 5.

EXAMPLE The following code fragment can be used as an example:

#include <stdio.h>
void myfunc(void)
{
      printf("%s\n", __func__);
      /* ... */
}

Each time the function is called, it will print to the standard output stream:

myfunc

universal-character-name:

\u hex-quad

\U hex-quad hex-quad

\u{ simple-hexadecimal-digit-sequence }

\U{ simple-hexadecimal-digit-sequence }

hex-quad:

hexadecimal-digit hexadecimal-digit hexadecimal-digit hexadecimal-digit

simple-hexadecimal-digit-sequence:

hexadecimal-digit

simple-hexadecimal-digit-sequence hexadecimal-digit

A universal character name shall not designate a code point where the hexadecimal value is:

• in the range D800 through DFFF inclusive; or
• greater than 10FFFF.⁶⁶⁾

A universal character name outside the c-char sequence of a character literal, or the s-char sequence of a string literal shall not designate a control character or a character in the basic character set.

Universal character names can be used in identifiers, character literals, and string literals to designate characters that are not in the basic character set.

A universal character name designates the character in ISO/IEC 10646 whose code point is the hexadecimal value represented by the sequence of hexadecimal digits in the universal character name.

constant:

integer-literal

floating-literal

enumeration-constant

character-literal

predefined-constant

Each constant shall have a type and the value of a constant shall be in the range of representable values for its type.

Each constant has a type, determined by its form and value, as detailed later.

integer-literal:

decimal-literal integer-suffix^opt

octal-literal integer-suffix^opt

hexadecimal-literal integer-suffix^opt

binary-literal integer-suffix^opt

decimal-literal:

nonzero-digit

decimal-literal ’^opt digit

hexadecimal-literal:

hexadecimal-prefix hexadecimal-digit-sequence

octal-literal:

prefixed-octal-literal

unprefixed-octal-literal

unprefixed-octal-literal:

0

0 ’^opt octal-digit-sequence

prefixed-octal-literal:

octal-prefix octal-digit-sequence

binary-literal:

binary-prefix binary-digit

binary-literal ’^opt binary-digit

hexadecimal-prefix: one of

0x 0X

octal-prefix: one of

0o 0O

binary-prefix: one of

0b 0B

nonzero-digit: one of

1 2 3 4 5 6 7 8 9

hexadecimal-digit-sequence:

hexadecimal-digit

hexadecimal-digit-sequence ’^opt hexadecimal-digit

octal-digit-sequence:

octal-digit

octal-digit-sequence ’^opt octal-digit

hexadecimal-digit: one of

0 1 2 3 4 5 6 7 8 9

a b c d e f

A B C D E F

octal-digit: one of

0 1 2 3 4 5 6 7

binary-digit: one of

0 1

integer-suffix:

unsigned-suffix long-suffix^opt

unsigned-suffix long-long-suffix

unsigned-suffix bit-precise-int-suffix

long-suffix unsigned-suffix^opt

long-long-suffix unsigned-suffix^opt

bit-precise-int-suffix unsigned-suffix^opt

bit-precise-int-suffix: one of

wb WB

unsigned-suffix: one of

u U

long-suffix: one of

l L

long-long-suffix: one of

ll LL

An integer literal begins with a digit, but has no period or exponent part. It can have a prefix that specifies its base and a suffix that specifies its type. An optional separating single quote character (’) in an integer or floating literal is called a digit separator. Digit separators are ignored when determining the value of the literal.

EXAMPLE 1 The following integer literals use digit separators; the comment associated with each literal shows the equivalent literal without digit separators.

0b11’10’11’01 /* 0b11101101 */
’1’2 /* character literal ’1’ followed by integer literal 2,
      not the integer literal 12 */
11’22 /* 1122 */
0x’FFFF’FFFF /* invalid hexadecimal literal (’ cannot appear after 0x) */
0x1’2’3’4AB’C’D /* 0x1234ABCD */

A decimal literal begins with a nonzero digit and consists of a sequence of decimal digits. An octal literal consists of the prefix 0o or 0O followed by a sequence of the digits 0 through 7 only. A hexadecimal literal consists of the prefix 0x or 0X followed by a sequence of the decimal digits and the letters a (or A) through f (or F) with values $10$ through $15$ respectively. A binary literal consists of the prefix 0b or 0B followed by a sequence of the digits 0 or 1.

An unprefixed octal literal begins with the digit 0 optionally followed by a sequence of the digits 0 through 7 only. Use of an unprefixed octal literal with digits other than 0 is an obsolescent feature.

The value of a decimal literal is computed base $10$; that of an octal literal, base $8$; that of a hexadecimal literal, base $16$; that of a binary literal, base $2$. The lexically first digit is the most significant.

The type of an integer literal is the first of the corresponding Table 6.2 in which its value can be represented.

Table 6.2 — Relationship between constants, suffixes, and types

Octal, Hexadecimal or Binary Suffix Decimal Literal Literal none int int long int unsigned int long long int long int unsigned long int long long int unsigned long long int u or U unsigned int unsigned int unsigned long int unsigned long int unsigned long long int unsigned long long int l or L long int long int long long int unsigned long int long long int unsigned long long int Both u or U unsigned long int unsigned long int and l or L unsigned long long int unsigned long long int ll or LL long long int long long int unsigned long long int Both u or U unsigned long long int unsigned long long int and ll or LL

wb or WB _BitInt(N) where the width N _BitInt(N) where the width N is the smallest N greater than 1 is the smallest N greater than 1 which can accommodate which can accommodate the value and the sign bit. the value and the sign bit. Both u or U unsigned _BitInt(N) where unsigned _BitInt(N) where and wb or WB the width N is the smallest N the width N is the smallest N greater than 0 which can greater than 0 which can accommodate the value. accommodate the value.

EXAMPLE 2 The wb suffix results in an _BitInt that includes space for the sign bit even if the value of the literal is positive or was specified in binary, octal, or hexadecimal notation.

-3wb   /* Yields a _BitInt(3) that is then arithmetically negated;
            two value bits, one sign bit */
-0x3wb /* Yields a _BitInt(3) that is then arithmetically negated;
            two value bits, one sign bit */
3wb    /* Yields a _BitInt(3); two value bits, one sign bit */
3uwb   /* Yields an unsigned _BitInt(2) */
-3uwb  /* Yields an unsigned _BitInt(2) that is then arithmetically
            negated, resulting in wraparound */

floating-literal:

decimal-floating-literal

hexadecimal-floating-literal

decimal-floating-literal:

fractional-literal exponent-part^opt floating-suffix^opt

digit-sequence exponent-part floating-suffix^opt

hexadecimal-floating-literal:

hexadecimal-prefix hexadecimal-fractional-literal

binary-exponent-part floating-suffix^opt

hexadecimal-prefix hexadecimal-digit-sequence

binary-exponent-part floating-suffix^opt

fractional-literal:

digit-sequence^opt . digit-sequence

digit-sequence .

exponent-part:

e sign^opt digit-sequence

E sign^opt digit-sequence

sign: one of

+ -

digit-sequence:

digit

digit-sequence ’^opt digit

hexadecimal-fractional-literal:

hexadecimal-digit-sequence^opt . hexadecimal-digit-sequence

hexadecimal-digit-sequence .

binary-exponent-part:

p sign^opt digit-sequence

P sign^opt digit-sequence

real-floating-suffix: one of

f l F L df dd dl DF DD DL

floating-suffix:

real-floating-suffix complex-suffix^opt

complex-suffix real-floating-suffix^opt

complex-suffix: one of

i I j J

A floating suffix df, dd, dl, DF, DD, or DL shall not be used in a hexadecimal floating literal. A floating suffix shall designate a type that the implementation provides.

A floating literal has a significand part that can be followed by an exponent part and a suffix that specifies its type. The components of the significand part can include a digit sequence representing the whole-number part, followed by a period ( .), followed by a digit sequence representing the fraction part. Digit separators (6.4.5.2) are ignored when determining the value of the literal. The components of the exponent part are an e, E, p, or P followed by an exponent consisting of an optionally signed digit sequence. Either the whole-number part or the fraction part has to be present; for decimal floating literals, either the period or the exponent part has to be present.

The significand part is interpreted as a (decimal or hexadecimal) rational number; the digit sequence in the exponent part is interpreted as a decimal integer. For decimal floating literals, the exponent indicates the power of $10$ by which the significand part is to be scaled. For hexadecimal floating literals, the exponent indicates the power of $2$ by which the significand part is to be scaled. For decimal floating literals, and also for hexadecimal floating literals when FLT_RADIX is not a power of $2$, the result is either the nearest representable value, or the larger or smaller representable value immediately adjacent to the nearest representable value, chosen in an implementation-defined manner. For hexadecimal floating literals when FLT_RADIX is a power of $2$, the result is correctly rounded.

The presence of a complex suffix indicates that the type of the literal is the complex type that corresponds to the type of the literal where the complex suffix is removed. The described floating value of such a complex literal designates the imaginary part of an arithmetic constant expression of the indicated complex type, the real part is (positive) zero.⁶⁷⁾

An unsuffixed floating literal has type double. If suffixed by a real floating suffix it has a type according to Table 6.3.

Table 6.3 — Suffixes for floating literals

Suffix Type f, F float l, L long double df, DF _Decimal32 dd, DD _Decimal64 dl, DL _Decimal128

The values of floating literals may be represented in greater range and precision than that required by the type (determined by the suffix); the types are not changed thereby. See 5.3.5.3.3 regarding evaluation formats.⁶⁸⁾

Floating literals of decimal floating type that have the same numerical value but different quantum exponents have distinguishable internal representations. The value shall be correctly rounded as specified in ISO/IEC 60559. The coefficient $c$ and the quantum exponent $q$ of a finite converted decimal floating-point number (see 5.3.5.3.4) are determined as follows:

• $q$ is set to the value of sign^opt digit-sequence in the exponent part, if any, or to $0$, otherwise.
• If there is a fractional literal, $q$ is decreased by the number of digits to the right of the period and the period is removed to form a digit sequence.
• $c$ is set to the value of the digit sequence (after any period has been removed).
• Rounding required because of insufficient precision or range in the type of the result will round $c$ to the full precision available in the type, and will adjust $q$ accordingly within the limits of the type, provided the rounding does not yield an infinity (in which case the result is an appropriately signed internal representation of infinity). If the full precision of the type would require $q$ to be smaller than the minimum for the type, then $q$ is pinned at the minimum and $c$ is adjusted through the subnormal range accordingly, perhaps to zero.

Floating literals are converted to internal format as if at translation-time. The conversion of a floating literal shall not raise an exceptional condition or a floating-point exception at execution time. All floating literals of the same source form⁶⁹⁾ shall convert to the same internal format and, provided they are subject to the same translation-time rounding direction (either the default or a constant rounding mode set by an FENV_ROUND or FENV_DEC_ROUND pragma), to the same value.

EXAMPLE Following are floating literals of type _Decimal64 and their values as triples $\left(s,c,q\right)$. For _Decimal64, the precision (maximum coefficient length) is $1$ 6 and the quantum exponent range is $-398\le q\le$ $369$.

0.dd $(+1,0,0)$ 0.00dd $(+1,0,-2)$ 123.dd $(+1,123,0)$ 1.23E3dd $(+1,123,1)$ 1.23E+3dd $(+1,123,1)$ 12.3E+7dd $(+1,123,6)$ 12.0dd $(+1,120,-1)$ 12.3dd $(+1,123,-1)$ 0.00123dd $(+1,123,-5)$ 1.23E-12dd $(+1,123,-14)$ 1234.5E-4dd $(+1,12345,-5)$ 0E+7dd $(+1,0,7)$ 12345678901234567890.dd $(+1,1234567890123457,$ 4) assuming default rounding and DEC_EVAL_METHOD is $0$ or 1⁷⁰⁾

1234E-400dd $(+1,12,-398)$ assuming default rounding and DEC_EVAL_METHOD is $0$ or $1$ 1234E-402dd $(+1,0,-398)$ assuming default rounding and DEC_EVAL_METHOD is $0$ or $1$ 1000.dd $(+1,1000,0)$ .0001dd $(+1,1,-4)$ 1000.e0dd $(+1,1000,0)$ .0001e0dd $(+1,1,-4)$ 1000.0dd $(+1,10000,-1)$ 0.0001dd $(+1,1,-4)$

The implementation should produce a diagnostic message if a hexadecimal floating literal cannot be represented exactly in its evaluation format; the implementation should then proceed with the translation of the program.

The translation-time conversion of floating literals should match the execution-time conversion of character strings by library functions, such as strtod, given matching inputs suitable for both conversions, the same result format, and default execution-time rounding.⁷¹⁾

NOTE 1 Floating literals do not include a sign and are arithmetically negated by the unary - operator (6.5.4.4) which arithmetically negates the rounded value of the literal. In contrast, the numeric conversion functions in the strto family (7.25.2.6, 7.25.2.7) can include the sign as part of the input value and convert and round the arithmetically negated input; implementations conforming to Annex F have this behavior. Negating before rounding and negating after rounding can yield different results, depending on the rounding direction and whether the results are correctly rounded. For example, the results are the same when both are correctly rounded using rounding to nearest or rounding toward zero, but the results are different when they are inexact and correctly rounded using rounding toward positive infinity or rounding toward negative infinity.

Conversions yielding exact results are not affected by the order of negating and rounding. For types with radix 10, decimal floating literals expressed within the precision and range of the evaluation format convert exactly. For types whose radix is a power of 2, hexadecimal floating literals expressed within the precision and range of the evaluation format convert exactly.

NOTE 2 Because complex literals are of complex type and have a (positive) zero real part, their use is problematic where signed zeros and infinities matter. For example, with ISO/IEC 60559 arithmetic and its default rounding,

-0.0 + 1.0i yields $-0+(+0+i)=+0+i$ -1.0i yields $-(+0+i)=-0-i$

INFINITY * 1.0i yields

$\infty \ast (+0+i)=$ NaN $+\infty i$, and raises the "invalid" floating-point exception when evaluated at execution time

The CMPLX macros in <complex.h> can be used to straightforwardly obtain particular values involving signed zeros and infinities. Corresponding to the preceding cases,

CMPLX(-0.0, 1.0) yields $-0+i$ CMPLX(0.0, -1.0) yields $+0-i$ CMPLX(0.0, INFINITY) yields $+0+\infty i$

Forward references: preprocessing numbers (6.4.9), numeric conversion functions (7.25.2), the strto function family (7.25.2.6, 7.25.2.7).

enumeration-constant:

identifier

An identifier declared as an enumeration constant for an enumeration without a fixed underlying type has either type int or the enumerated type, as defined in 6.7.3.3. An identifier declared as an enumeration constant for an enumeration with a fixed underlying type has the associated enumerated type.

An enumeration constant can be used in an expression (or constant expression) wherever a value of an integer type may be used.

character-literal:

encoding-prefix^opt ’ c-char-sequence ’

encoding-prefix: one of

u8 u U L

c-char-sequence:

c-char

c-char-sequence c-char

c-char:

any member of the source character set except

the single-quote ’, backslash \, or new-line character

escape-sequence

escape-sequence:

simple-escape-sequence

octal-escape-sequence

hexadecimal-escape-sequence

universal-character-name

simple-escape-sequence: one of

\‘ \" \? \\

\a \b \f \n \r \t \v

octal-escape-sequence:

\ octal-digit

\ octal-digit octal-digit

\ octal-digit octal-digit octal-digit

\o{ simple-octal-digit-sequence }

simple-octal-digit-sequence:

octal-digit

simple-octal-digit-sequence octal-digit

hexadecimal-escape-sequence:

\x simple-hexadecimal-digit-sequence

\x{ simple-hexadecimal-digit-sequence }

An ordinary character literal is a sequence of one or more multibyte characters enclosed in singlequotes, as in ’x’. A UTF-8 character literal is the same, except prefixed by u8. Together ordinary and UTF-8 character literal are narrow character literals. A wchar_t character literal is prefixed by the letter L. A UTF-16 character literal is prefixed by the letter u. A UTF-32 character literal is prefixed by the letter U. Collectively, wchar_t, UTF-16, and UTF-32 character literals are called wide character literals. With a few exceptions detailed later, the elements of the sequence are any members of the source character set; they are mapped in an implementation-defined manner to members of the execution character set.

The single-quote ’, the double-quote ", the question-mark ?, the backslash \, and arbitrary integer values are representable according to Table 6.7:

Table 6.7 — Escape sequences

single quote ’ \‘ double quote " \" question mark ? \? backslash \ \\ octal character \octal digits hexadecimal character \x hexadecimal digits

The double-quote " and question-mark ? are representable either by themselves or by the escape sequences \" and \?, respectively, but the single-quote ’ and the backslash \ shall be represented, respectively, by the escape sequences \’ and \\.

The octal digits that follow the backslash in an octal escape sequence are taken to be part of the construction of a single character for a narrow character literal or of a single wide character for a wide character literal. The numerical value of the octal integer so formed specifies the value of the desired character or wide character.

The hexadecimal digits that follow the backslash and the letter x in a hexadecimal escape sequence are taken to be part of the construction of a single character for a narrow character literal or of a single wide character for a wide character literal. The numerical value of the hexadecimal integer so formed specifies the value of the desired character or wide character.

Each octal or hexadecimal escape sequence is the longest sequence of characters that can constitute the escape sequence.

In addition, characters not in the basic character set are representable by universal character names and certain non-graphic characters are representable by escape sequences consisting of the backslash \ followed by a lowercase letter: \a, \b, \f, \n, \r, \t, and \v.⁷²⁾

The value of an octal or hexadecimal escape sequence shall be in the range of representable values for the corresponding type, as dictated by Table 6.8:

Table 6.8 — Types provided by prefixes

Prefix Corresponding Type none unsigned char u8 char8_t L the unsigned type corresponding to wchar_t

:

u char16_t

U char32_t

A UTF-8, UTF-16, or UTF-32 character literal shall not contain more than one character.⁷³⁾ The value shall be representable with a single UTF-8, UTF-16, or UTF-32 code unit, respectively.

An ordinary character literal has type int. The value of an ordinary character literal containing a single character that maps to a single value in the literal encoding (6.2.9) is the numerical value of the representation of the mapped character in the literal encoding interpreted as an integer. The value of an ordinary character literal containing more than one character (e.g. ’ab’), or containing a character or escape sequence that does not map to a single value in the literal encoding, is implementationdefined. If an ordinary character literal contains a single character or escape sequence, its value is the one that results when an object with type char whose value is that of the single character or escape sequence is converted to type int.

A UTF-8 character literal has type char8_t. If the UTF-8 character literal is not produced through a hexadecimal or octal escape sequence, the value of a UTF-8 character literal is equal to its ISO/IEC 10646 code point value, provided that the code point value can be encoded as a single UTF-8 code unit. Otherwise, the value of the UTF-8 character literal is the numeric value specified in the hexadecimal or octal escape sequence.

A UTF-16 character literal has type char16_t which is an unsigned integer type defined in the <uchar.h> header. If the UTF-16 character literal is not produced through a hexadecimal or octal escape sequence, the value of a UTF-16 character literal is equal to its ISO/IEC 10646 code point value, provided that the code point value can be encoded as a single UTF-16 code unit. Otherwise, the value of the UTF-16 character literal is the numeric value specified in the hexadecimal or octal escape sequence.

A UTF-32 character literal has type char32_t which is an unsigned integer type defined in the <uchar.h> header. If the UTF-32 character literal is not produced through a hexadecimal or octal escape sequence, the value of a UTF-32 character literal is equal to its ISO/IEC 10646 code point value, provided that the code point value can be encoded as a single UTF-32 code unit. Otherwise, the value of the UTF-32 character literal is the numeric value specified in the hexadecimal or octal escape sequence.

A wchar_t character literal has type wchar_t, an integer type defined in the <stddef.h> header. The value of a wchar_t character literal containing a single multibyte character that maps to a single member of the extended execution character set is the wide character corresponding to that multibyte character in the implementation-defined wide literal encoding (6.2.9). The value of a wchar_t character literal 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, is implementation-defined.

EXAMPLE 1 The construction ’\0’ is commonly used to represent the null character.

EXAMPLE 2 Implementations that use eight bits for objects that have type char can furnish certain values in an variety of ways. In an implementation in which type char has the same range of values as signed char, the ordinary character literal ’\xFF’ has the value $-1$; if type char has the same range of values as unsigned char, the ordinary character literal ’\xFF’ has the value $+255$.

EXAMPLE 3 Even if eight bits are used for objects that have type char, the construction ’\x123’ specifies an ordinary character literal containing only one character, because a hexadecimal escape sequence is terminated only by a non-hexadecimal character. To specify an ordinary character literal containing the two characters whose values are ’\x12’ and ’3’, the construction ’\0223’ can be used, because an octal escape sequence is terminated after three octal digits. (The value of this two-character ordinary character literal is implementationdefined.)

EXAMPLE 4 Even if 12 or more bits are used for objects that have type wchar_t, the construction L’\1234’ specifies the implementation-defined value that results from the combination of the values 0123 and ’4’.

predefined-constant:

false

true

nullptr

Some keywords represent constants of a specific value and type.

The keywords false and true are constants of type bool with a value of 0 for false and 1 for true.⁷⁴⁾

The keyword nullptr represents a null pointer constant. Details of its type are described in 7.22.3.

string-literal:

encoding-prefix^opt " s-char-sequence^opt "

s-char-sequence:

s-char

s-char-sequence s-char

s-char:

any member of the source character set except

the double-quote ", backslash \, or new-line character

escape-sequence

If a sequence of adjacent string literal tokens includes prefixed string literal tokens, the prefixed tokens shall all have the same prefix.

An ordinary string literal is a sequence of zero or more multibyte characters enclosed in double-quotes, as in "xyz". A UTF-8 string literal is the same, except prefixed by u8. A wchar_t string literal is the same, except prefixed by L. A UTF-16 string literal is the same, except prefixed by u. A UTF-32 string literal is the same, except prefixed by U. Collectively, wchar_t, UTF-16, and UTF-32 string literals are called wide string literals.

The same considerations apply to each element of the sequence in a string literal as if it were in an narrow character literal (for a character or UTF-8 string literal) or a wide character literal (for a wide string literal), except that the single-quote ’ is representable either by itself or by the escape sequence \’, but the double-quote " shall be represented by the escape sequence \".

In translation phase 6 (5.2.1.2), the multibyte character sequences specified by any sequence of adjacent character and identically-prefixed string literal tokens are concatenated into a single multibyte character sequence. If any of the tokens has an encoding prefix, the resulting multibyte

In translation phase 7 (5.2.1.2), a byte or code of value zero is appended to each multibyte character sequence that results from a string literal or literals.⁷⁵⁾ The multibyte character sequence is then used to initialize an array of static storage duration and length just sufficient to contain the sequence. For ordinary string literals, the array elements have type char, and are initialized with the individual bytes of the multibyte character sequence corresponding to the literal encoding (6.2.9). For UTF-8 string literals, the array elements have type char8_t, and are initialized with the characters of the multibyte character sequence, as encoded in UTF-8. For wide string literals prefixed by the letter L, the array elements have type wchar_t and are initialized with the sequence of wide characters corresponding to the wide literal encoding. For wide string literals prefixed by the letter u or U, the array elements have type char16_t or char32_t, respectively, and are initialized with the sequence of wide characters corresponding to UTF-16 and UTF-32 encoded text, respectively. The value of a string literal containing a multibyte character or escape sequence not represented in the execution character set is implementation-defined. Any hexadecimal escape sequence or octal escape sequence specified in a u8, u, or U string specifies a single char8_t, char16_t, or char32_t value and can result in the full character sequence not being valid UTF-8, UTF-16, or UTF-32.

It is unspecified whether these arrays are distinct provided their elements have the appropriate values. If the program attempts to modify such an array, the behavior is undefined.

EXAMPLE 1 This pair of adjacent ordinary string literals

"\x12" "3"

produces a single ordinary string literal containing the two characters whose values are ’\x12’ and ’3’, because escape sequences are converted into single members of the execution character set just prior to adjacent string literal concatenation.

EXAMPLE 2 Each of the sequences of adjacent string literal tokens

"a" "b" L"c"
"a" L"b" "c"
L"a" "b" L"c"
L"a" L"b" L"c"

L"abc"

"a" "b" u"c"
"a" u"b" "c"
u"a" "b" u"c"
u"a" u"b" u"c"

u"abc"

Forward references: common definitions <stddef.h> (7.22), the mbstowcs function (7.25.9.2), Unicode utilities <uchar.h> (7.32).

punctuator: one of

[ ] ( ) { } . ->

++ -- & * + - ~ !

/ % << >> < > <= >= == != ^ | && ||

? : :: ; ...

= *= /= %= += -= <<= >>= &= ^= |=

, # ##

<: :> <% %> %: %:%:

A punctuator is a symbol that has independent syntactic and semantic significance. Depending on context, it may specify an operation to be performed (which in turn may yield a value or a function designator, produce a side effect, or some combination thereof) in which case it is known as an operator (other forms of operator also exist in some contexts). An operand is an entity on which an operator acts.

In all aspects of the language, the six tokens⁷⁶⁾

<: :> <% %> %: %:%:

behave, respectively, the same as the six tokens

[ ] { } # ##

except for their spelling.⁷⁷⁾

header-name:

< h-char-sequence >

" q-char-sequence "

h-char-sequence:

h-char

h-char-sequence h-char

h-char:

any member of the source character set except

the new-line character and >

q-char-sequence:

q-char

q-char-sequence q-char

q-char:

any member of the source character set except

the new-line character and "

The sequences in both forms of header names are mapped in an implementation-defined manner to headers or external source file names as specified in 6.10.3.

If the characters ’, \, ", //, or /* occur in the sequence between the < and > delimiters, the behavior is undefined. Similarly, if the characters ’, \, //, or /* occur in the sequence between the " delimiters,

EXAMPLE The following sequence of characters:

0x3<1/a.h>1e2
#include <1/a.h>
#define const.member@$

{0x3}{<}{1}{/}{a}{.}{h}{>}{1e2}
{#}{include} {<1/a.h>}
{#}{define} {const}{.}{member}{@}{$}

pp-number:

digit

. digit

pp-number identifier-continue

pp-number ’ digit

pp-number ’ nondigit

pp-number e sign

pp-number E sign

pp-number p sign

pp-number P sign

pp-number .

A preprocessing number begins with a digit optionally preceded by a period (.) and may be followed by valid identifier characters and the character sequences e+, e-, E+, E-, p+, p-, P+, or P-.

Preprocessing number tokens lexically include all floating and integer literals.

A preprocessing number does not have type or a value; it acquires both after a successful conversion (as part of translation phase 7 (5.2.1.2)) to a floating or integer literal. This notwithstanding for the evaluation of expressions within conditional source inclusion (6.10.2) and to determine the limit parameter for binary resource inclusion (6.10.4), preprocessing numbers which have the form of an integer literal are interpreted as such. For the determination of a line number in a #line directive (6.10.6), digit sequences that match the requirements for a preprocessing number are interpreted as numbers as well and the interpretation is of a decimal integer, even if the leading digit is 0.

A source file shall not end in a partial comment.

Except within a character literal, a string literal, or a comment, the characters /* introduce a comment. The contents of such a comment are examined only to identify multibyte characters and to find the characters */ that terminate it.⁸⁰⁾

Except within a character literal, a string literal, or a comment, the characters // introduce a comment that includes all multibyte characters up to, but not including, the next new-line character. The contents of such a comment are examined only to identify multibyte characters and to find the terminating new-line character.

EXAMPLE

"a//b"                   // four-character ordinary string literal
#include "//e"           // undefined behavior
// */                    // comment, not syntax error
f = g/**//h;             // equivalent to f = g / h;
//\
i();                     // part of a two-line comment
/\
/ j();                   // part of a two-line comment
#define glue(x,y) x##y
glue(/,/) k();           // syntax error, not comment
/*//*/ l();              // equivalent to l();
m = n//**/o
  + p;                   // equivalent to m = n + p;

During lvalue conversion, an lvalue shall not have an incomplete type.

An expression is a sequence of operators and operands that specifies computation of a value, or that designates an object or a function, or that generates side effects, or that performs a combination thereof. The value computations of the operands of an operator are sequenced before the value computation of the result of the operator.

If a side effect on a scalar object is unsequenced relative to either a different side effect on the same scalar object or a value computation using the value of the same scalar object, the behavior is undefined. If there are multiple allowable orderings of the subexpressions of an expression, the behavior is undefined if such an unsequenced side effect occurs in any of the orderings.⁸¹⁾

The grouping of operators and operands is indicated by the syntax.⁸²⁾ Except as specified later, side effects and value computations of subexpressions are unsequenced.⁸³⁾

Some operators (the unary operator ~, and the binary operators <<, >>, &, ^, and |, collectively described as bitwise operators) are required to have operands that have integer type. These operators yield values that depend on the internal representations of integers, and have implementationdefined and undefined aspects for signed types.

If an exceptional condition occurs during the evaluation of an expression (that is, if the result is not mathematically defined or not in the range of representable values for its type), the behavior is undefined.

The effective type of an object that is not a byte array, for an access to its stored value, is the declared type of the object.⁸⁴⁾ If a value is stored into a byte array through an lvalue having a type that is not a byte type, then the type of the lvalue becomes the effective type of the object for that access and for subsequent accesses that do not modify the stored value. If a value is copied into a byte array using memcpy or memmove, or is copied as an array of byte type, then the effective type of the modified object for that access and for subsequent accesses that do not modify the value is the effective type of the object from which the value is copied, if it has one. For all other accesses to a byte array, the effective type of the object is simply the type of the lvalue used for the access.⁸⁵⁾

Following a byte-level copy operation, an object of atomic type (6.7.3.5) has an indeterminate representation and a copy of a FILE (7.24.3) object is not required to serve in place of the original.

An object shall have its stored value accessed only by an lvalue expression that has one of the following types:⁸⁶⁾

• a type compatible with the effective type of the object,
• a qualified version of a type compatible with the effective type of the object,
• the signed or unsigned type corresponding to a type compatible with the underlying type of the effective type of the object,
• the signed or unsigned type corresponding to a type compatible with a qualified version of the underlying type of the effective type of the object,
• a byte type, or
• an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union).

A floating expression may be contracted, that is, evaluated as though it were a single operation, thereby omitting rounding errors implied by the source code and the expression evaluation method.⁸⁷⁾

The FP_CONTRACT pragma in <math.h> provides a way to disallow contracted expressions. Otherwise, whether and how expressions are contracted is implementation-defined.⁸⁸⁾

Operators involving decimal floating types are evaluated according to the semantics of ISO/IEC 60559, including production of results with the preferred quantum exponent as specified in ISO/IEC 60559.

primary-expression:

identifier

constant

string-literal

( expression )

generic-selection

The identifier in an identifier primary expression shall have a visible declaration as an ordinary identifier that declares an object or a function.⁸⁹⁾

An identifier primary expression designating an object is an lvalue. An identifier primary expression designating a function is a function designator.

A constant is a primary expression. Its type depends on its form and value, as detailed in 6.4.5.

A string literal is a primary expression. It is an lvalue with type as detailed in 6.4.6.

A parenthesized expression is a primary expression. Its type, value, and semantics are identical to those of the unparenthesized expression.

A generic selection is a primary expression. Its type, value, and semantics depend on the selected generic association, as detailed in the following subclause.

generic-selection:

_Generic ( generic-controlling-operand , generic-assoc-list )

generic-controlling-operand:

assignment-expression

type-name

generic-assoc-list:

generic-association

generic-assoc-list , generic-association

generic-association:

type-name : assignment-expression

default : assignment-expression

A generic selection shall have no more than one default generic association. No two generic associations in the same generic selection shall specify compatible types. If the generic controlling operand is an assignment expression, the controlling type of the generic selection expression is the type of the assignment expression as if it had undergone an lvalue conversion,⁹⁰⁾ array to pointer conversion, or function to pointer conversion. Otherwise, the controlling type of the generic selection expression is the type designated by the type name. The controlling type shall be compatible with at most one of the types named in the generic association list. If a generic selection has no default generic association, its controlling type shall be compatible with exactly one of the types named in its generic association list.

The generic controlling operand, size expressions, and typeof operators contained in the type names of generic associations are not evaluated. If a generic selection has a generic association with a type name that is compatible with the controlling type, then the result expression of the generic selection is the expression in that generic association. Otherwise, the result expression of the generic selection is the expression in the default generic association. None of the expressions from any other generic association of the generic selection is evaluated.

The type and value of a generic selection are identical to those of its result expression. It is an lvalue, a function designator, or a void expression if its result expression is, respectively, an lvalue, a function designator, or a void expression.

EXAMPLE 1 A cbrt type-generic macro can be implemented as follows:

#define cbrt(X) _Generic((X),                   \
                        long double: cbrtl,     \
                        default: cbrt,          \
                        float: cbrtf            \
                        )(X)