Programming languages — C (INTERNATIONAL STANDARD ISO/IEC 9899:TC3)

Foreword

ISO (the International Organization for Standardization) and IEC (the International
Electrotechnical Commission) form the specialized system for worldwide
standardization. National bodies that are member of ISO or IEC participate in the
development of International Standards through technical committees established by the
respective org anization 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.

International Standards are drafted in accordance with the rules given in the ISO/IEC
Directives, Part 3.

In the field of information technology, ISO and IEC have established a joint technical
committee, ISO/IEC JTC 1. Draft International Standards adopted by the joint technical
committee are circulated to national bodies for voting. Publication as an International
Standard requires approval by at least 75% of the national bodies casting a vote.

International Standard ISO/IEC 9899 was prepared by Joint Technical Committee
ISO/IEC JTC 1, Information technology, Subcommittee SC 22, Programming languages,
their environments and system software interfaces. The Working Group responsible for
this standard (WG 14) maintains a site on the World Wide Web at

http://www.open-std.org/JTC1/SC22/WG14/

containing additional

information relevant to this standard such as a Rationale for many of the decisions made
during its preparation and a log of Defect Reports and Responses.

This second edition cancels and replaces the first edition, ISO/IEC 9899:1990, as
amended and corrected by ISO/IEC 9899/COR1:1994, ISO/IEC 9899/AMD1:1995, and
ISO/IEC 9899/COR2:1996. Major changes from the previous edition include:

— restricted character set support via digraphs and

<iso646.h>

(originally specified

in AMD1)

— wide character library support in

<wchar.h>

and

<wctype.h>

(originally

specified in AMD1)

— more precise aliasing rules via effective type

— restricted pointers

— variable length arrays

— flexible array members

—

static

and type qualifiers in parameter array declarators

— complex (and imaginary) support in

<complex.h>

— type-generic math macros in

<tgmath.h>

— the

long long int

type and library functions

Foreword xi

— increased minimum translation limits

— additional floating-point characteristics in

<float.h>

— remove implicit

int

— reliable integer division

— universal character names (

and

)

— extended identifiers

— hexadecimal floating-point constants and

and

%A printf

scanf

conversion

specifiers

— compound literals

— designated initializers

—

comments

— extended integer types and library functions in

<inttypes.h>

and

<stdint.h>

— remove implicit function declaration

— preprocessor arithmetic done in

intmax_t

uintmax_t

— mixed declarations and code

— new block scopes for selection and iteration statements

— integer constant type rules

— integer promotion rules

— macros with a variable number of arguments

— the

vscanf

family of functions in

<stdio.h>

and

<wchar.h>

— additional math library functions in

<math.h>

— treatment of error conditions by math library functions (

math_errhandling

)

— floating-point environment access in

<fenv.h>

— IEC 60559 (also known as IEC 559 or IEEE arithmetic) support

— trailing comma allowed in

enum

declaration

—

%lf

conversion specifier allowed in

printf

— inline functions

— the

snprintf

family of functions in

<stdio.h>

— boolean type in

<stdbool.h>

— idempotent type qualifiers

— empty macro arguments

xii Foreword

— new structure type compatibility rules (tag compatibility)

— additional predefined macro names

—

_Pragma

preprocessing operator

— standard pragmas

—

_ _func_ _

predefined identifier

—

va_copy

macro

— additional

strftime

conversion specifiers

— LIA compatibility annex

— deprecate

ungetc

at the beginning of a binary file

— remove deprecation of aliased array parameters

— conversion of array to pointer not limited to lvalues

— relaxed constraints on aggregate and union initialization

— relaxed restrictions on portable header names

—

return

without expression not permitted in function that returns a value (and vice

versa)

Annexes D and F form a normative part of this standard; annexes A, B, C, E, G, H, I, J,
the bibliography, and the index are for information only. In accordance with Part 3 of the
ISO/IEC Directives, this foreword, the introduction, notes, footnotes, and examples are
also for information only.

Foreword xiii

Introduction

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

Certain features are obsolescent, which means that they may be considered for
withdrawal in future revisions of this International Standard. 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.26]) is discouraged.

This International Standard 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).

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 International Standard. References are used to refer to
other related subclauses. Recommendations are provided to give advice or guidance to
implementors. Annexes provide additional information and summarize the information
contained in this International Standard. A bibliography lists documents that were
referred to during the preparation of the standard.

The language clause (clause 6) is derived from ‘‘The C Reference Manual’’.

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

xiv

Introduction

INTERNATIONAL STANDARD

Programming languages — C

1. Scope

This International Standard specifies the form and establishes the interpretation of
programs written in the C programming language.

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 International Standard 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;

This International Standard is designed to promote the portability of C programs among a variety of
data-processing systems. It is intended for use by implementors and programmers.

§1 General

— all minimal requirements of a data-processing system that is capable of supporting a

conforming implementation.

2. Normative references

The following normative documents contain provisions which, through reference in this
text, constitute provisions of this International Standard.

For dated references,

subsequent amendments to, or revisions of, any of these publications do not apply.
However, parties to agreements based on this International Standard are encouraged to
investigate the possibility of applying the most recent editions of the normative
documents indicated below. For undated references, the latest edition of the normative
document referred to applies. Members of ISO and IEC maintain registers of currently
valid International Standards.

ISO 31−11:1992, Quantities and units — Part 11: Mathematical signs and symbols for
use in the physical sciences and technology.

ISO/IEC 646, Information technology —

ISO

7-bit coded character set for information

interchange.

ISO/IEC 2382−1:1993, Information technology — Vocabulary — Part 1: Fundamental
terms.

ISO 4217, Codes for the representation of currencies and funds.

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

ISO/IEC 10646 (all parts), Information technology — Universal Multiple-Octet Coded
Character Set (UCS).

IEC 60559:1989, Binary floating-point arithmetic for microprocessor systems (previously
designated IEC 559:1989).

General §2

3. Terms, definitions, and symbols

For the purposes of this International Standard, the following definitions apply. Other
terms are defined where they appear in italic type or on the left side of a syntax rule.
Terms explicitly defined in this International Standard are not to be presumed to refer
implicitly to similar terms defined elsewhere. Terms not defined in this International
Standard are to be interpreted according to ISO/IEC 2382−1. Mathematical symbols not
defined in this International Standard are to be interpreted according to ISO 31−11.

3.1

access

〈

execution-time action

〉

to read or modify the value of an object

NOTE 1

Where only one of these two actions is meant, ‘‘read’’ or ‘‘modify’’ is used.

NOTE 2

"Modify’’ includes the case where the new value being stored is the same as the previous value.

NOTE 3

Expressions that are not evaluated do not access objects.

3.2

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

3.3

argument
actual argument
actual parameter (deprecated)
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

3.4

behavior
external appearance or action

3.4.1

implementation-defined behavior
unspecified behavior where each implementation documents how the choice is made

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

3.4.2

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

§3.4.2 General

EXAMPLE An example of locale-specific behavior is whether the

islower

function returns true for

characters other than the 26 lowercase Latin letters.

3.4.3

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

NOTE 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).

EXAMPLE An example of undefined behavior is the behavior on integer overflow.

3.4.4

unspecified behavior
use of an unspecified value, or other behavior where this International Standard provides
two or more possibilities and imposes no further requirements on which is chosen in any
instance

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

3.5

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

NOTE It need not be possible to express the address of each individual bit of an object.

3.6

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

NOTE 1

It is possible to express the address of each individual byte of an object uniquely.

NOTE 2

A byte is composed of a contiguous sequence of bits, the number of which is implementation-

defined. The least significant bit is called the low-order bit; the most significant bit is called the high-order
bit.

3.7

character

〈

abstract

〉

member of a set of elements used for the organization, control, or

representation of data

3.7.1

character
single-byte character

〈

〉

bit representation that fits in a byte

General §3.7.1

3.7.2

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 The extended character set is a superset of the basic character set.

3.7.3

wide character
bit representation that fits in an object of type

wchar_t

, capable of representing any

character in the current locale

3.8

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

3.9

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

3.10

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

3.11

forward reference
reference to a later subclause of this International Standard that contains additional
information relevant to this subclause

3.12

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

3.13

implementation limit
restriction imposed upon programs by the implementation

3.14

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

§3.14 General

NOTE When referenced, an object may be interpreted as having a particular type; see 6.3.2.1.

3.15

parameter
formal parameter
formal argument (deprecated)
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

3.16

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

3.17

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

3.17.1

implementation-defined value
unspecified value where each implementation documents how the choice is made

3.17.2

indeterminate value
either an unspecified value or a trap representation

3.17.3

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

NOTE An unspecified value cannot be a trap representation.

3.18





ceiling of x: the least integer greater than or equal to x

EXAMPLE



2. 4



is 3,

−

2. 4



is −2.

3.19





floor of x: the greatest integer less than or equal to x

EXAMPLE



2. 4



is 2,

−

2. 4



is −3.

General §3.19

4. Conformance

In this International Standard, ‘‘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 is violated, the
behavior is undefined. Undefined behavior is otherwise indicated in this International
Standard 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.1.2.3.

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

It shall not produce output dependent on any

unspecified, undefined, or implementation-defined behavior, and shall not exceed any
minimum implementation limit.

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 that does not
use complex types and 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>

<stdarg.h>

<stdbool.h>

<stddef.h>

, and

<stdint.h>

. A conforming implementation may have extensions (including additional

library functions), provided they do not alter the behavior of any strictly conforming
program.

A strictly conforming program can use conditional features (such as those in annex F) provided the
use is guarded by a

#ifdef

directive with the appropriate macro. For example:

#ifdef _ _STDC_IEC_559_ _ /* FE_UPWARD defined */

...

fesetround(FE_UPWARD);

...

#endif

This implies that a conforming implementation reserves no identifiers other than those explicitly
reserved in this International Standard.

§4 General

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.

Forward references:

conditional inclusion (6.10.1), error directive (6.10.5),

characteristics of floating types

<float.h>

(7.7), alternative spellings

<iso646.h>

(7.9), sizes of integer types

<limits.h>

(7.10), variable arguments

<stdarg.h>

(7.15), boolean type and values

<stdbool.h>

(7.16), common definitions

<stddef.h>

(7.17), integer types

<stdint.h>

(7.18).

Strictly conforming programs are intended to be maximally portable among conforming
implementations. Conforming programs may depend upon nonportable features of a conforming
implementation.

General §4

5. Environment

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 International Standard. Their characteristics define and
constrain the results of executing conforming C programs constructed according to the
syntactic and semantic rules for conforming implementations.

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

5.1 Conceptual models

5.1.1 Translation environment

5.1.1.1 Program structure

A C program need not all be translated at the same time. The text of the program is kept
in units called source files, (or preprocessing files) in this International Standard. 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 may 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.

Forward references:

linkages of identifiers (6.2.2), external definitions (6.9),

preprocessing directives (6.10).

5.1.1.2 Translation phases

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.

Trigraph sequences are replaced by

corresponding single-character internal representations.

Implementations shall behave as if these separate phases occur, even though many are typically folded
together in practice. Source files, translation units, and translated translation units need not
necessarily be stored as files, nor need there be any one-to-one correspondence between these entities
and any external representation. The description is conceptual only, and does not specify any
particular implementation.

§5.1.1.2 Environment 9

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. A source file that is not empty shall end in a new-line character,
which shall not be immediately preceded by a backslash character before any such
splicing takes place.

3. The source file is decomposed into preprocessing tokens

and sequences of

white-space characters (including comments). A source file shall not end in a
partial preprocessing token or in a partial comment. 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. If a character sequence that

matches the syntax of a universal character name is produced by token
concatenation (6.10.3.3), the behavior is undefined. 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 constants and

string literals is converted to the corresponding member of the execution character
set; if there is no corresponding member, it is converted to an implementation-
defined member 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.

Forward references:

universal character names (6.4.3), lexical elements (6.4),

preprocessing directives (6.10), trigraph sequences (5.2.1.1), external definitions (6.9).

As described in 6.4, the process of dividing a source file’s characters into preprocessing tokens is
context-dependent. For example, see the handling of

within a

#include

preprocessing directive.

An implementation need not convert all non-corresponding source characters to the same execution
character.

10 Environment §5.1.1.2

5.1.1.3 Diagnostics

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 need not be
produced in other circumstances.

EXAMPLE An implementation shall issue a diagnostic for the translation unit:

char i;

int i;

because in those cases where wording in this International Standard describes the behavior for a construct
as being both a constraint error and resulting in undefined behavior, the constraint error shall be diagnosed.

5.1.2 Execution environments

Tw o 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.

Forward references: storage durations of objects (6.2.4), initialization (6.7.8).

5.1.2.1 Freestanding environment

In a freestanding environment (in which C program execution may 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.

5.1.2.2 Hosted environment

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

The intent is that an implementation should identify the nature of, and where possible localize, each
violation. Of course, an implementation is free to produce any number of diagnostics as long as a
valid program is still correctly translated. It may also successfully translate an invalid program.

§5.1.2.2 Environment 11

5.1.2.2.1 Program startup

The function called at program startup is named

main

. The implementation declares no

prototype for this function. It shall be defined with a return type of

int

and with no

parameters:

int main(void) { /*

...

*/ }

or with two parameters (referred to here as

argc

and

argv

, though any names may be

used, as they are local to the function in which they are declared):

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

...

*/ }

or equivalent;

or in some other implementation-defined manner.

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

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.

5.1.2.2.2 Program execution

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

Thus,

int

can be replaced by a typedef name defined as

int

, or the type of

argv

can be written as

char ** argv

, and so on.

12 Environment §5.1.2.2.2

5.1.2.2.3 Program termination

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;

10)

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.

Forward references: definition of terms (7.1.1), the

exit

function (7.20.4.3).

5.1.2.3 Program execution

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

Accessing a volatile object, modifying an object, modifying a file, or calling a function
that does any of those operations are all side effects,

11)

which are changes in the state of

the execution environment. Evaluation of an expression may produce side effects. At
certain specified points in the execution sequence called sequence points, all side effects
of previous evaluations shall be complete and no side effects of subsequent evaluations
shall have taken place. (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 need not 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 accessing a volatile object).

When the processing of the abstract machine is interrupted by receipt of a signal, only the
values of objects as of the previous sequence point may be relied on. Objects that may be
modified between the previous sequence point and the next sequence point need not have
received their correct values yet.

The least requirements on a conforming implementation are:

— At sequence points, volatile objects are stable in the sense that previous accesses are

complete and subsequent accesses have not yet occurred.

10) In accordance with 6.2.4, the lifetimes of objects with automatic storage duration declared in

main

will have ended in the former case, even where they would not have in the latter.

11) The IEC 60559 standard for binary floating-point arithmetic requires certain user-accessible status

flags and control modes. Floating-point operations implicitly set the status flags; modes affect result
values of floating-point operations. Implementations that support such floating-point state are
required to regard changes to it as side effects — see annex F for details. The floating-point
environment library

<fenv.h>

provides a programming facility for indicating when these side

effects matter, freeing the implementations in other cases.

§5.1.2.3 Environment 13

— 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.19.3. The intent of these requirements is that unbuffered or line-buffered output
appear as soon as possible, to ensure that prompting messages actually appear prior to
a program waiting for input.

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 might 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 might 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

int

s and truncate the sum. Provided the addition of two

char

s can be done without

overflow, or with 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 may be executed using single-precision arithmetic if the implementation can ascertain
that the result would be the same as if it were executed using double-precision arithmetic (for example, if

were replaced by the constant

2.0

, which has type

double

14 Environment §5.1.2.3

EXAMPLE 4

Implementations employing wide registers have 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 is not permitted to alter the value. Also, an explicit store and load
is required to round to the precision of the storage type. In particular, casts and assignments are required to
perform their specified conversion. For the fragment

double d1, d2;

float f;

d1 = f =

expression

;

d2 = (float)

expression

;

the values assigned to

and

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 constants in order to
rearrange expressions. In the following fragment, rearrangements suggested by mathematical rules for real
numbers are often not valid (see F.8).

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;

the expression statement behaves exactly the same as

a = (((a + 32760) + b) + 5);

due to the associativity and precedence of these operators. Thus, the result of the sum

(a + 32760)

next added to

, and that result is then added to

which results in the value assigned to

. On a machine in

which overflows produce an explicit trap and in which the range of values representable by an

int

[−32768, +32767], the implementation cannot rewrite this expression as

a = ((a + b) + 32765);

since if the values for

and

were, respectively, −32754 and −15, the sum

a + b

would produce a trap

while the original expression would not; nor can the expression be rewritten either as

a = ((a + 32765) + b);

a = (a + (b + 32765));

since the values for

and

might have been, respectively, 4 and −8 or −17 and 12. However, on a machine

in which overflow silently generates some value and where positive and negative overflows cancel, the
above expression statement can be rewritten by the implementation in any of the above ways because the
same result will occur.

§5.1.2.3 Environment 15

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());

the expression statement is grouped as if it were written as

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

but the actual increment of

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), type qualifiers (6.7.3), statements (6.8), the

signal

function (7.14), files (7.19.3).

16 Environment §5.1.2.3

5.2 Environmental considerations

5.2.1 Character sets

Tw o 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 constant 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 26 lowercase letters of the Latin alphabet

the 10 decimal digits

the following 29 graphic characters

(

)

;

[

]

{

}

the space character, and control characters representing horizontal tab, vertical tab, and
form feed. The representation of each member of the source and execution basic
character sets shall fit in a byte. In both the source and execution basic character sets, the
value of each character after

in the above list of decimal digits shall be one greater than

the value of the previous. In source files, there shall be some way of indicating the end of
each line of text; this International Standard treats such an end-of-line indicator as if it
were a single new-line character. In the basic execution character set, there shall be
control characters representing alert, backspace, carriage return, and new line. If any
other characters are encountered in a source file (except in an identifier, a character
constant, a string literal, a header name, a comment, or a preprocessing token that is never

§5.2.1 Environment 17

converted to a token), the behavior is undefined.

A letter is an uppercase letter or a lowercase letter as defined above; in this International
Standard 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.

Forward references: universal character names (6.4.3), character constants (6.4.4.4),
preprocessing directives (6.10), string literals (6.4.5), comments (6.4.9), string (7.1.1).

5.2.1.1 Trigraph sequences

Before any other processing takes place, each occurrence of one of the following
sequences of three characters (called trigraph sequences

12)

) is replaced with the

corresponding single character.

??= #

??( [

??/ \

??) ]

??' ^

??< {

??! |

??> }

??- ~

No other trigraph sequences exist. Each

that does not begin one of the trigraphs listed

above is not changed.

EXAMPLE 1

??=define arraycheck(a, b) a??(b??) ??!??! b??(a??)

becomes

#define arraycheck(a, b) a[b] || b[a]

EXAMPLE 2

The following source line

printf("Eh???/n");

becomes (after replacement of the trigraph sequence

??/

)

printf("Eh?\n");

5.2.1.2 Multibyte characters

The source character set may contain multibyte characters, used to represent members of
the extended character set. The execution character set may also contain multibyte
characters, which need not 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.

12) The trigraph sequences enable the input of characters that are not defined in the Invariant Code Set as

described in ISO/IEC 646, which is a subset of the seven-bit US ASCII code set.

18 Environment §5.2.1.2

— A multibyte character set may 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 constant, or header name shall begin

and end in the initial shift state.

— An identifier, comment, string literal, character constant, or header name shall consist

of a sequence of valid multibyte characters.

5.2.2 Character display semantics

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 nongraphic characters in the execution
character set are intended to produce actions on display devices as follows:

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

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

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

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

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

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

(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

§5.2.2 Environment 19

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

need not be identical to the internal representations, and are outside the scope of this
International Standard.

Forward references: the

isprint

function (7.4.1.8), the

fputc

function (7.19.7.3).

5.2.3 Signals and interrupts

Functions shall be implemented such that they may be interrupted at any time by a signal,
or may 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.

5.2.4 Environmental limits

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.

5.2.4.1 Translation limits

The implementation shall be able to translate and execute at least one program that
contains at least one instance of every one of the following limits:

13)

— 127 nesting levels of blocks

— 63 nesting levels of conditional inclusion

— 12 pointer, array, and function declarators (in any combinations) modifying an

arithmetic, structure, union, or incomplete type in a declaration

— 63 nesting levels of parenthesized declarators within a full declarator

— 63 nesting levels of parenthesized expressions within a full expression

— 63 significant initial characters in an internal identifier or a macro name (each

universal character name or extended source character is considered a single
character)

— 31 significant initial characters in an external identifier (each universal character name

specifying a short identifier of 0000FFFF or less is considered 6 characters, each

13) Implementations should avoid imposing fixed translation limits whenever possible.

20 Environment §5.2.4.1

Returns

The

mbsinit

function returns nonzero if

is a null pointer or if the pointed-to object

describes an initial conversion state; otherwise, it returns zero.

7.24.6.3 Restartable multibyte/wide character conversion functions

These functions differ from the corresponding multibyte character functions of 7.20.7
(

mblen

mbtowc

, and

wctomb

) in that they hav e an extra parameter,

, of type

pointer to

mbstate_t

that points to an object that can completely describe the current

conversion state of the associated multibyte character sequence. If

is a null pointer,

each function uses its own internal

mbstate_t

object instead, which is initialized at

program startup to the initial conversion state. The implementation behaves as if no
library function calls these functions with a null pointer for

Also unlike their corresponding functions, the return value does not represent whether the
encoding is state-dependent.

7.24.6.3.1 The

mbrlen

function

Synopsis

#include <wchar.h>

size_t mbrlen(const char * restrict s,

size_t n,

mbstate_t * restrict ps);

Description

The

mbrlen

function is equivalent to the call:

mbrtowc(NULL, s, n, ps != NULL ? ps : &internal)

where

internal

is the

mbstate_t

object for the

mbrlen

function, except that the

expression designated by

is evaluated only once.

Returns

The

mbrlen

function returns a value between zero and

, inclusive,

(size_t)(-2)

(size_t)(-1)

Forward references: the

mbrtowc

function (7.24.6.3.2).

388 Library

§7.24.6.3.1

universal character name specifying a short identifier of 00010000 or more is
considered 10 characters, and each extended source character is considered the same
number of characters as the corresponding universal character name, if any)

14)

— 4095 external identifiers in one translation unit

— 511 identifiers with block scope declared in one block

— 4095 macro identifiers simultaneously defined in one preprocessing translation unit

— 127 parameters in one function definition

— 127 arguments in one function call

— 127 parameters in one macro definition

— 127 arguments in one macro invocation

— 4095 characters in a logical source line

— 4095 characters in a character string literal or wide string literal (after concatenation)

— 65535 bytes in an object (in a hosted environment only)

— 15 nesting levels for

#include

d files

— 1023

case

labels for a

switch

statement (excluding those for any nested

switch

statements)

— 1023 members in a single structure or union

— 1023 enumeration constants in a single enumeration

— 63 lev els of nested structure or union definitions in a single struct-declaration-list

5.2.4.2 Numerical limits

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>

Forward references: integer types

<stdint.h>

(7.18).

5.2.4.2.1 Sizes of integer types

<limits.h>

The values given below shall be replaced by constant expressions suitable for use in

#if

preprocessing directives. Moreover, except for

CHAR_BIT

and

MB_LEN_MAX

, the

following shall be replaced by expressions that have the same type as would an
expression that is an object of the corresponding type converted according to the integer
promotions. Their implementation-defined values shall be equal or greater in magnitude

14) See ‘‘future language directions’’ (6.11.3).

§5.2.4.2.1 Environment 21

(absolute value) to those shown, with the same sign.

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

CHAR_BIT 8

— minimum value for an object of type

signed char

SCHAR_MIN -127 //

−

— maximum value for an object of type

signed char

SCHAR_MAX +127 //

−

— maximum value for an object of type

unsigned char

UCHAR_MAX 255 //

−

— minimum value for an object of type

char

CHAR_MIN

see below

— maximum value for an object of type

char

CHAR_MAX

see below

— maximum number of bytes in a multibyte character, for any supported locale

MB_LEN_MAX 1

— minimum value for an object of type

short int

SHRT_MIN -32767 //

−

— maximum value for an object of type

short int

SHRT_MAX +32767 //

−

— maximum value for an object of type

unsigned short int

USHRT_MAX 65535 //

−

— minimum value for an object of type

int

INT_MIN -32767 //

−

— maximum value for an object of type

int

INT_MAX +32767 //

−

— maximum value for an object of type

unsigned int

UINT_MAX 65535 //

−

— minimum value for an object of type

long int

LONG_MIN -2147483647 //

−

— maximum value for an object of type

long int

LONG_MAX +2147483647 //

−

— maximum value for an object of type

unsigned long int

ULONG_MAX 4294967295 //

−

22 Environment §5.2.4.2.1

7.24.6.3.3 The

wcrtomb

function

Synopsis

#include <wchar.h>

size_t wcrtomb(char * restrict s,

wchar_t wc,

mbstate_t * restrict ps);

Description

is a null pointer, the

wcrtomb

function is equivalent to the call

wcrtomb(buf, L'\0', ps)

where

buf

is an internal buffer.

is not a null pointer, the

wcrtomb

function determines the number of bytes needed

to represent the multibyte character that corresponds to the wide character given by

(including any shift sequences), and stores the multibyte character representation in the
array whose first element is pointed to by

. At most

MB_CUR_MAX

bytes are stored. If

is a null wide character, a null byte is stored, preceded by any shift sequence needed

to restore the initial shift state; the resulting state described is the initial conversion state.

Returns

The

wcrtomb

function returns the number of bytes stored in the array object (including

any shift sequences). When

is not a valid wide character, an encoding error occurs:

the function stores the value of the macro

EILSEQ

errno

and returns

(size_t)(-1)

; the conversion state is unspecified.

7.24.6.4 Restartable multibyte/wide string conversion functions

These functions differ from the corresponding multibyte string functions of 7.20.8
(

mbstowcs

and

wcstombs

) in that they hav e an extra parameter,

, of type pointer to

mbstate_t

that points to an object that can completely describe the current conversion

state of the associated multibyte character sequence. If

is a null pointer, each function

uses its own internal

mbstate_t

object instead, which is initialized at program startup

to the initial conversion state. The implementation behaves as if no library function calls
these functions with a null pointer for

Also unlike their corresponding functions, the conversion source parameter,

src

, has a

pointer-to-pointer type. When the function is storing the results of conversions (that is,
when

dst

is not a null pointer), the pointer object pointed to by this parameter is updated

to reflect the amount of the source processed by that invocation.

390 Library

§7.24.6.4

— minimum value for an object of type

long long int

LLONG_MIN -9223372036854775807 //

−

— maximum value for an object of type

long long int

LLONG_MAX +9223372036854775807 //

−

— maximum value for an object of type

unsigned long long int

ULLONG_MAX 18446744073709551615 //

−

If the value of an object of type

char

is treated as a signed integer when used in an

expression, 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

15)

The value

UCHAR_MAX

shall equal 2

CHAR_BIT

−

Forward references: representations of types (6.2.6), conditional inclusion (6.10.1).

5.2.4.2.2 Characteristics of floating types

<float.h>

The characteristics of floating types are defined in terms of a model that describes a
representation of floating-point numbers and values that provide information about an
implementation’s floating-point arithmetic.

16)

The following parameters are used to

define the model for each floating-point type:

sign (

base or radix of exponent representation (an integer > 1)

exponent (an integer between a minimum e

min

and a maximum e

max

)

precision (the number of base-b digits in the significand)

nonnegative integers less than b (the significand digits)

A floating-point number (x) is defined by the following model:

−

min

≤

max

In addition to normalized floating-point numbers ( f

> 0 if x

≠

0), floating types may be

able to contain other kinds of floating-point numbers, such as subnormal floating-point
numbers (x

≠

0, e

min

, f

0) and unnormalized floating-point numbers (x

≠

e > e

min

, f

0), and values that are not floating-point numbers, such as infinities and

NaNs. A NaN is an encoding 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

15) See 6.2.5.

16) The floating-point model is intended to clarify the description of each floating-point characteristic and

does not require the floating-point arithmetic of the implementation to be identical.

§5.2.4.2.2 Environment 23

arithmetic operand.

17)

An implementation may give zero and non-numeric values (such as infinities and NaNs) a
sign or may leave them unsigned. Wherever such values are unsigned, any requirement
in this International Standard to retrieve the sign shall produce an unspecified sign, and
any requirement to set the sign shall be ignored.

The accuracy of the floating-point operations (

) and 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.

All integer values in the

<float.h>

header, except

FLT_ROUNDS

, shall be constant

expressions suitable for use in

#if

preprocessing directives; all floating values shall be

constant expressions. All except

DECIMAL_DIG

FLT_EVAL_METHOD

FLT_RADIX

and

FLT_ROUNDS

have separate names for all three floating-point types. The floating-

point model representation is provided for all values except

FLT_EVAL_METHOD

and

FLT_ROUNDS

The rounding mode for floating-point addition is characterized by the implementation-
defined value of

FLT_ROUNDS

18)

-1

indeterminable

toward zero

to nearest

toward positive infinity

toward negative infinity

All other values for

FLT_ROUNDS

characterize implementation-defined rounding

behavior.

Except for assignment and cast (which remove all extra range and precision), the values
of operations with floating operands and values subject to the usual arithmetic
conversions and of floating constants are evaluated to a format whose range and precision
may be greater than required by the type. The use of evaluation formats is characterized
by the implementation-defined value of

FLT_EVAL_METHOD

19)

17) IEC 60559:1989 specifies quiet and signaling NaNs. For implementations that do not support

IEC 60559:1989, the terms quiet NaN and signaling NaN are intended to apply to encodings with
similar behavior.

18) Evaluation of

FLT_ROUNDS

correctly reflects any execution-time change of rounding mode through

the function

fesetround

<fenv.h>

24 Environment §5.2.4.2.2

Programming languages — C (INTERNATIONAL STANDARD ISO/IEC 9899:TC3) - page 2