JTC1/SC22/WG14
N794
Programming languages - C
Contents
1. Scope................................................... 1
2. Normative references.................................... 2
3. Definitions and conventions............................. 3
4. Compliance.............................................. 7
5. Environment............................................. 9
5.1 Conceptual models................................. 9
5.1.1 Translation environment.................. 9
5.1.2 Execution environments................... 12
5.2 Environmental considerations...................... 20
5.2.1 Character sets........................... 20
5.2.2 Character display semantics.............. 23
5.2.3 Signals and interrupts................... 24
5.2.4 Environmental limits..................... 24
6. Language................................................ 34
6.1 Lexical elements.................................. 34
6.1.1 Keywords................................. 36
6.1.2 Identifiers.............................. 37
6.1.3 Constants................................ 53
6.1.4 String literals.......................... 61
6.1.5 Operators................................ 63
6.1.6 Punctuators.............................. 64
6.1.7 Header names............................. 65
6.1.8 Preprocessing numbers.................... 66
6.1.9 Comments................................. 67
6.2 Conversions....................................... 68
6.2.1 Arithmetic operands...................... 68
6.2.2 Other operands........................... 73
6.3 Expressions....................................... 77
6.3.1 Primary expressions...................... 79
6.3.2 Postfix operators........................ 81
6.3.3 Unary operators.......................... 91
6.3.4 Cast operators........................... 96
6.3.5 Multiplicative operators................. 97
6.3.6 Additive operators....................... 98
6.3.7 Bitwise shift operators.................. 101
6.3.8 Relational operators..................... 102
6.3.9 Equality operators....................... 103
6.3.10 Bitwise AND operator..................... 104
6.3.11 Bitwise exclusive OR operator............ 105
6.3.12 Bitwise inclusive OR operator............ 105
6.3.13 Logical AND operator..................... 106
6.3.14 Logical OR operator...................... 106
6.3.15 Conditional operator..................... 107
6.3.16 Assignment operators..................... 109
6.3.17 Comma operator........................... 111
6.4 Constant expressions.............................. 113
6.5 Declarations...................................... 116
6.5.1 Storage-class specifiers................. 117
6.5.2 Type specifiers.......................... 119
6.5.3 Type qualifiers.......................... 129
6.5.4 Function specifiers...................... 135
6.5.5 Declarators.............................. 137
6.5.6 Type names............................... 147
6.5.7 Type definitions......................... 148
6.5.8 Initialization........................... 151
6.6 Statements........................................ 160
6.6.1 Labeled statements....................... 160
6.6.2 Compound statement, or block............. 161
6.6.3 Expression and null statements........... 162
6.6.4 Selection statements..................... 163
6.6.5 Iteration statements..................... 165
6.6.6 Jump statements.......................... 167
6.7 External definitions.............................. 171
6.7.1 Function definitions..................... 172
6.7.2 External object definitions.............. 175
6.8 Preprocessing directives.......................... 177
6.8.1 Conditional inclusion.................... 180
6.8.2 Source file inclusion.................... 182
6.8.3 Macro replacement........................ 184
6.8.4 Line control............................. 193
6.8.5 Error directive.......................... 194
6.8.6 Pragma directive......................... 194
6.8.7 Null directive........................... 195
6.8.8 Predefined macro names................... 195
6.8.9 Pragma operator.......................... 196
6.9 Future language directions........................ 198
6.9.1 Character escape sequences............... 198
6.9.2 Storage-class specifiers................. 198
6.9.3 Function declarators..................... 198
6.9.4 Function definitions..................... 198
6.9.5 Pragma directives........................ 198
7. Library................................................. 199
7.1 Introduction...................................... 199
7.1.1 Definitions of terms..................... 199
7.1.2 Standard headers......................... 200
7.1.3 Reserved identifiers..................... 202
7.1.4 Errors <errno.h>......................... 203
7.1.5 Limits <float.h> and <limits.h>.......... 204
7.1.6 Common definitions <stddef.h>............ 204
7.1.7 Boolean type and values <stdbool.h>...... 205
7.1.8 Use of library functions................. 206
7.2 Diagnostics <assert.h>............................ 209
7.2.1 Program diagnostics...................... 209
7.3 Character handling <ctype.h>...................... 211
7.3.1 Character testing functions.............. 211
7.3.2 Character case mapping functions......... 216
7.4 Integer types <inttypes.h>........................ 217
7.4.1 Typedef names for integer types.......... 218
7.4.2 Limits of specified-width integer
types.................................... 220
7.4.3 Macros for integer constants............. 223
7.4.4 Macros for format specifiers............. 224
7.4.5 Limits of other integer types............ 226
7.4.6 Conversion functions for greatest-width
integer types............................ 228
7.5 Localization <locale.h>........................... 230
7.5.1 Locale control........................... 231
7.5.2 Numeric formatting convention
inquiry.................................. 233
7.6 Floating-point environment <fenv.h>............... 237
7.6.1 The FENV_ACCESS pragma................... 239
7.6.2 Exceptions............................... 241
7.6.3 Rounding................................. 244
7.6.4 Environment.............................. 245
7.7 Mathematics <math.h>.............................. 248
7.7.1 Treatment of error conditions............ 251
7.7.2 The FP_CONTRACT pragma................... 252
7.7.3 Classification macros.................... 252
7.7.4 Trigonometric functions.................. 256
7.7.5 Hyperbolic functions..................... 259
7.7.6 Exponential and logarithmic
functions................................ 261
7.7.7 Power and absolute value functions....... 267
7.7.8 Error and gamma functions................ 270
7.7.9 Nearest integer functions................ 271
7.7.10 Remainder functions...................... 275
7.7.11 Manipulation functions................... 277
7.7.12 Maximum, minimum, and positive
difference functions..................... 279
7.7.13 Floating multiply-add.................... 281
7.7.14 Comparison macros........................ 281
7.8 Complex arithmetic <complex.h>.................... 285
7.8.1 The CX_LIMITED_RANGE pragma.............. 286
7.8.2 Complex functions........................ 287
7.9 Type-generic math <tgmath.h>...................... 297
7.9.1 Type-generic macros...................... 297
7.10 Nonlocal jumps <setjmp.h>......................... 301
7.10.1 Save calling environment................. 301
7.10.2 Restore calling environment.............. 302
7.11 Signal handling <signal.h>........................ 304
7.11.1 Specify signal handling.................. 305
7.11.2 Send signal.............................. 307
7.12 Variable arguments <stdarg.h>..................... 308
7.12.1 Variable argument list access
macros................................... 308
7.13 Input/output <stdio.h>............................ 313
7.13.1 Introduction............................. 313
7.13.2 Streams.................................. 315
7.13.3 Files.................................... 317
7.13.4 Operations on files...................... 320
7.13.5 File access functions.................... 323
7.13.6 Formatted input/output functions......... 328
7.13.7 Character input/output functions......... 354
7.13.8 Direct input/output functions............ 361
7.13.9 File positioning functions............... 362
7.13.10 Error-handling functions................. 365
7.14 General utilities <stdlib.h>...................... 368
7.14.1 String conversion functions.............. 369
7.14.2 Pseudo-random sequence generation
functions................................ 379
7.14.3 Memory management functions.............. 380
7.14.4 Communication with the environment....... 383
7.14.5 Searching and sorting utilities.......... 386
7.14.6 Integer arithmetic functions............. 388
7.14.7 Multibyte character functions............ 391
7.14.8 Multibyte string functions............... 394
7.15 String handling <string.h>........................ 396
7.15.1 String function conventions.............. 396
7.15.2 Copying functions........................ 396
7.15.3 Concatenation functions.................. 398
7.15.4 Comparison functions..................... 400
7.15.5 Search functions......................... 403
7.15.6 Miscellaneous functions.................. 407
7.16 Date and time <time.h>............................ 409
7.16.1 Components of time....................... 409
7.16.2 Time manipulation functions.............. 411
7.16.3 Time conversion functions................ 417
7.17 Alternative spellings <iso646.h>.................. 424
7.18 Wide-character classification and mapping
utilities <wctype.h>.............................. 425
7.18.1 Introduction............................. 425
7.18.2 Wide-character classification
utilities................................ 426
7.18.3 Wide-character mapping utilities......... 433
7.19 Extended multibyte and wide-character utilities
<wchar.h>......................................... 436
7.19.1 Introduction............................. 436
7.19.2 Formatted wide-character input/output
functions................................ 437
7.19.3 Wide-character input/output
functions................................ 459
7.19.4 General wide-string utilities............ 465
7.19.5 The wcsftime function.................... 486
7.19.6 The wcsfxtime function................... 487
7.19.7 Extended multibyte and wide-character
conversion utilities..................... 487
7.20 Future library directions......................... 496
7.20.1 Errors <errno.h>......................... 496
7.20.2 Character handling <ctype.h>............. 496
7.20.3 Integer types <inttypes.h>............... 496
7.20.4 Localization <locale.h>.................. 496
7.20.5 Signal handling <signal.h>............... 496
7.20.6 Input/output <stdio.h>................... 497
7.20.7 General utilities <stdlib.h>............. 497
7.20.8 Complex arithmetic <complex.h>........... 497
7.20.9 String handling <string.h>............... 497
7.20.10 Wide-character classification and
mapping utilities <wctype.h>............. 498
7.20.11 Extended multibyte and wide-character
utilities <wchar.h>...................... 498
A Bibliography............................................ 499
B Language syntax summary................................. 501
B.1 Lexical grammar................................... 501
B.2 Phrase structure grammar.......................... 507
B.3 Preprocessing directives.......................... 513
C Sequence points......................................... 515
D Library summary......................................... 516
D.1 Errors <errno.h>.................................. 516
D.2 Common definitions <stddef.h>..................... 516
D.3 Boolean type and values <stdbool.h>............... 516
D.4 Diagnostics <assert.h>............................ 516
D.5 Character handling <ctype.h>...................... 517
D.6 Integer types <inttypes.h>........................ 517
D.7 Floating-point environment <fenv.h>............... 523
D.8 Localization <locale.h>........................... 523
D.9 Mathematics <math.h>.............................. 524
D.10 Complex <complex.h>............................... 528
D.11 Type-generic math <tgmath.h>...................... 529
D.12 Nonlocal jumps <setjmp.h>......................... 530
D.13 Signal handling <signal.h>........................ 531
D.14 Variable arguments <stdarg.h>..................... 531
D.15 Input/output <stdio.h>............................ 531
D.16 General utilities <stdlib.h>...................... 534
D.17 String handling <string.h>........................ 536
D.18 Date and time <time.h>............................ 537
D.19 Alternative spellings <iso646.h>.................. 537
D.20 Wide-character classification and mapping
utilities <wctype.h>.............................. 538
D.21 Extended multibyte and wide-character utilities
<wchar.h>......................................... 538
E Implementation limits................................... 543
F IEC 559 floating-point arithmetic....................... 545
F.1 Introduction...................................... 545
F.2 Types............................................. 545
F.3 Operators and functions........................... 546
F.4 Floating to integer conversion.................... 548
F.5 Binary-decimal conversion......................... 549
F.6 Contracted expressions............................ 549
F.7 Environment....................................... 550
F.8 Optimization...................................... 553
F.9 <math.h>.......................................... 558
G IEC 559-compatible complex arithmetic................... 573
G.1 Introduction...................................... 573
G.2 Types............................................. 573
G.3 Conversions....................................... 573
G.4 Binary operators.................................. 574
G.5 <complex.h>....................................... 580
G.6 <tgmath.h>........................................ 588
H Language independent arithmetic......................... 590
H.1 Introduction...................................... 590
H.2 Types............................................. 590
H.3 Notification...................................... 594
I Universal character names for identifiers............... 597
J Common warnings......................................... 599
K Portability issues...................................... 601
K.1 Unspecified behavior.............................. 601
K.2 Undefined behavior................................ 604
K.3 Implementation-defined behavior................... 620
K.4 Locale-specific behavior.......................... 629
K.5 Common extensions................................. 630
Index....................................................... 633
page 1
1. Scope
[#1] This International Standard specifies the form and
establishes the interpretation of programs written in the C
programming language.1 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.
[#2] 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;
__________
1. 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.
page 1 General
page 2
- all minimal requirements of a data-processing system
that is capable of supporting a conforming
implementation.
2. Normative references
[#1] The following standards contain provisions which,
through reference in this text, constitute provisions of
this International Standard. At the time of publication,
the editions indicated were valid. All standards are
subject to revision, and parties to agreements based on this
International Standard are encouraged to investigate the
possibility of applying the most recent editions of the
standards indicated below. Members of IEC and ISO maintain
registers of currently valid International Standards.
IEC 559:1993, Binary floating-point arithmetic for
microprocessor systems, second edition.
ISO 646:1983, Information processing - ISO 7-bit coded
character set for information interchange.
ISO/IEC 2382-1:1993, Information technology -
Vocabulary - Part 1: Fundamental terms.
ISO 4217:1987, Codes for the representation of
currencies and funds.
ISO 8601:1988, Data elements and interchange formats -
Information interchange - Representation of dates and
times.
ISO/IEC TR 10176, Information technology - Guidelines
for the preparation of programming language standards.
ISO/IEC 10646-1:1993, Information technology -
Universal Multiple-Octet Coded Character Set (UCS) -
Part 1: Architecture and Basic Multilingual Plane.
page 2 General
page 3
3. Definitions and conventions
[#1] 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.
[#2] For the purposes of this International Standard, the
following definitions apply. Other terms are defined where
they appear in italic type or being 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 2382-1.
3.1 Alignment
[#1] A requirement that objects of a particular type be
located on storage boundaries with addresses that are
particular multiples of a byte address.
3.2 Argument
[#1] An 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.
Also known as ``actual argument'' or ``actual parameter.''
3.3 Bit
[#1] The unit of data storage in the execution environment
large enough to hold an object that may have one of two
values. It need not be possible to express the address of
each individual bit of an object.
page 3 General
page 4
3.4 Byte
[#1] The unit of data storage large enough to hold any
member of the basic character set of the execution
environment. It shall be possible to express the address of
each individual byte of an object uniquely. 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.5 Character
[#1] A bit representation that fits in a byte. The
representation of each member of the basic character set in
both the source and execution environments shall fit in a
byte.
3.6 Constraints
[#1] Restrictions, both syntactic and semantic, by which the
exposition of language elements is to be interpreted.
3.7 Correctly rounded result
[#1] A representation in the result format that is nearest
in value, subject to the effective rounding mode, to what
the result would be given unlimited range and precision.
3.8 Diagnostic message
[#1] A message belonging to an implementation-defined subset
of the implementation's message output.
3.9 Forward references
[#1] References to later subclauses of this International
Standard that contain additional information relevant to
this subclause.
page 4 General
page 5
3.10 Implementation
[#1] A 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.11 Implementation-defined behavior
[#1] Unspecified behavior where each implementation shall
document how the choice is made.
3.12 Implementation limits
[#1] Restrictions imposed upon programs by the
implementation.
3.13 Locale-specific behavior
[#1] Behavior that depends on local conventions of
nationality, culture, and language that each implementation
shall document.
3.14 Multibyte character
[#1] A sequence of one or more bytes representing a member
of the extended character set of either the source or the
execution environment. The extended character set is a
superset of the basic character set.
3.15 Object
[#1] A region of data storage in the execution environment,
the contents of which can represent values. 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.
When referenced, an object may be interpreted as having a
particular type; see 6.2.2.1.
page 5 General
page 6
3.16 Parameter
[#1] An 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. Also known as ``formal
argument'' or ``formal parameter.''
3.17 Recommended practice
[#1] Sections so entitled contain specification that is
strongly recommended as being in keeping with the intent of
the standard, but that may be impractical for some
implementations.
3.18 Undefined behavior
[#1] Behavior, upon use of a nonportable or erroneous
program construct, of erroneous data, or of indeterminately
valued objects, for which this International Standard
imposes no requirements. Permissible 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).
[#2] 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.''
[#3] The implementation must successfully translate a given
program unless a syntax error is detected, a constraint is
violated, or it can determine that every possible execution
of that program would result in undefined behavior.
page 6 General
page 7
3.19 Unspecified behavior
[#1] Behavior where this International Standard provides two
or more possibilities and imposes no requirements on which
is chosen in any instance. 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 subclause 5.1.2.3.
Examples
[#2]
1. An example of unspecified behavior is the order in
which the arguments to a function are evaluated.
2. An example of undefined behavior is the behavior on
integer overflow.
3. An example of implementation-defined behavior is the
propagation of the high-order bit when a signed
integer is shifted right.
4. An example of locale-specific behavior is whether the
islower function returns true for characters other
than the 26 lowercase Latin letters.
Forward references: bitwise shift operators (6.3.7),
expressions (6.3), function calls (6.3.2.2), the islower
function (7.3.1.7), localization (7.5).
4. Compliance
[#1] A strictly conforming program shall use only those
features of the language and library specified in this
International Standard.2 It shall not produce output
__________
2. This implies that a strictly conforming program can use
features in a conditionally normative annex provided the
use is conditioned by a #ifdef directive with the
conformance macro for the annex, as in
#ifdef __STDC_IEC_559__ /* FE_UPWARD defined */
/* ... */
fesetround(FE_UPWARD);
/* ... */
page 7 General
page 8
dependent on any unspecified, undefined, or implementation-
defined behavior, and shall not exceed any minimum
implementation limit.
[#2] 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>, <limits.h>,
<stdarg.h>, <stddef.h>, and <iso646.h>. A conforming
implementation may have extensions (including additional
library functions), provided they do not alter the behavior
of any strictly conforming program.3
[#3] A conforming program is one that is acceptable to a
conforming implementation.4
[#4] An implementation shall be accompanied by a document
that defines all implementation-defined characteristics and
all extensions.
Forward references: limits <float.h> and <limits.h>
(7.1.5), variable arguments <stdarg.h> (7.12), common
definitions <stddef.h> (7.1.6), alternate spellings
<iso646.h> (7.17).
____________________________________________________________
#endif
3. This implies that a conforming implementation reserves
no identifiers other than those explicitly reserved in
this International Standard.
4. Strictly conforming programs are intended to be
maximally portable among conforming implementations.
Conforming programs may depend upon nonportable features
of a conforming implementation.
page 8 General
page 9
5. Environment
[#1] 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 the environment clause (clause 5),
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
[#1] A C program need not all be translated at the same
time. The text of the program is kept in units called
source files, also known as 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: conditional inclusion (6.8.1), linkages
of identifiers (6.1.2.2), source file inclusion (6.8.2),
external definitions (6.7), preprocessing directives (6.8).
page 9 Environment
page 10
5.1.1.2 Translation phases
[#1] The precedence among the syntax rules of translation is
specified by the following phases.5
1. Physical source file multibyte characters are mapped
to the source character set (introducing new-line
characters for end-of-line indicators) if necessary.
Any multibyte source file character not in the basic
source character set is replaced by the universal-
character-name that designates that multibyte
character.6 Then, trigraph sequences are replaced by
corresponding single-character internal
representations.
2. Each instance of a backslash character immediately
followed by a newline 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
tokens7 and sequences of white-space characters
__________
5. Implementations must behave as if these separate phases
occur, even though many are typically folded together in
practice.
6. The process of handling extended characters is specified
in terms of mapping to an encoding that uses only the
basic source character set, and, in the case of
character literals and strings, further mapping to the
execution character set. In practical terms, however,
any internal encoding may be used, so long as an actual
extended character encountered in the input, and the
same extended character expressed in the input as a
universal-character-name (i.e., using the \U or \u
notation), are handled equivalently.
7. As described in 6.1, 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.
page 10 Environment
page 11
(including comments). A source file shall not end in
a partial preprocessing token or 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.8.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, escape sequence, and
universal-character-name in character constants and
string literals is converted to a member of the
execution character set.
6. Adjacent character string literal tokens are
concatenated and adjacent wide 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.
Constraints
[#2] A universal-character-name shall not specify a
character short identifier in the range 0000 through 0020 or
007F through 009F inclusive. A universal-character-name
shall not designate a character in the basic source
character set.
page 11 Environment
page 12
Forward references: lexical elements (6.1), preprocessing
directives (6.8), trigraph sequences (5.2.1.1), external
definitions (6.7).
5.1.1.3 Diagnostics
[#1] 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.8
Examples
[#2] 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
[#1] 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 in static storage 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.
__________
8. 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.
page 12 Environment
page 13
Forward references: initialization (6.5.8).
5.1.2.1 Freestanding environment
[#1] 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 are implementation-
defined.
[#2] The effect of program termination in a freestanding
environment is implementation-defined.
5.1.2.2 Hosted environment
[#1] A hosted environment need not be provided, but shall
conform to the following specifications if present.
5.1.2.2.1 Program startup
[#1] The function called at program startup is named main.
The implementation declares no prototype for this function.
It shall be defined 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,9 or in some other implementation-defined
manner.
[#2] If they are defined, 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.
__________
9. 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.
page 13 Environment
page 14
- 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.
5.1.2.2.2 Program execution
[#1] In a hosted environment, a program may use all the
functions, macros, type definitions, and objects described
in the library clause (clause 7).
5.1.2.2.3 Program termination
[#1] 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 If the }
that terminates the main function is reached, the
termination status returned to the host environment is
unspecified.
__________
10. In accordance with subclause 6.1.2.4, objects with
automatic storage duration declared in main will no
longer have storage guaranteed to be reserved in the
former case even where they would in the latter.
page 14 Environment
page 15
Forward references: definition of terms (7.1.1), the exit
function (7.14.4.3).
5.1.2.3 Program execution
[#1] The semantic descriptions in this International
Standard describe the behavior of an abstract machine in
which issues of optimization are irrelevant.
[#2] 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.
[#3] 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).
[#4] 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.
[#5] An instance of each object with automatic storage
duration is associated with each entry into its block. Such
__________
11. The IEC 559 standard for binary floating-point
arithmetic requires certain status flags and control
modes, with user access. Floating-point operations
implicitly set the status flags; modes affect result
values of floating-point operations. Implementations
that support such floating-point state will need 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.
page 15 Environment
page 16
an object exists and retains its last-stored value during
the execution of the block and while the block is suspended
(by a call of a function or receipt of a signal).
[#6] The least requirements on a conforming implementation
are:
- At sequence points, volatile objects are stable in the
sense that previous evaluations are complete and
subsequent evaluations have not yet occurred.
- 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.13.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.
[#7] What constitutes an interactive device is
implementation-defined.
[#8] More stringent correspondences between abstract and
actual semantics may be defined by each implementation.
Examples
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
page 16 Environment
page 17
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.
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
overflow, or with overflow wrapping silently to
produce the correct result, the actual execution need
only produce the same result, possibly omitting the
promotions.
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 d were replaced by the constant 2.0, which
has type double).
4. Implementations employing wide registers must take
care to honor appropriate semantics. Values must be
independent of whether they are represented in a
register or in memory. For example, an implicit
spilling of a register must not alter the value.
Also, an explicit store and load must round to the
precision of the storage type. In particular, casts
and assignments must perform their specified
conversion: for the fragment
double d1, d2;
float f;
d1 = f = expression;
d2 = (float) expressions;
page 17 Environment
page 18
the values assigned to d1 and d2 must have been
converted to float.
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 Annex 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 of y = x * 0.2;
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) is
next added to b, and that result is then added to 5
which results in the value assigned to a. On a
machine in which overflows produce an explicit trap
and in which the range of values representable by an
int is [-32768, + 32767], the implementation cannot
rewrite this expression as
a = ((a + b) + 32765);
since if the values for a and b 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
page 18 Environment
page 19
a = ((a + 32765) + b);
or
a = (a + (b + 32765));
since the values for a and b 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.
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 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: compound statement, or block (6.6.2),
expressions (6.3), files (7.13.3),
sequence points (6.6), the signal function (7.11),
type qualifiers (6.5.3).
page 19 Environment
page 20
5.2 Environmental considerations
5.2.1 Character sets
[#1] Two sets of characters and their associated collating
sequences shall be defined: the set in which source files
are written, and the set interpreted in the execution
environment. The values of the members of the execution
character set are implementation-defined; any additional
members beyond those required by this subclause are locale-
specific.
[#2] 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.
[#3] Both the basic source and basic execution character
sets shall have at least the following members: the 26
uppercase letters of the Latin alphabet
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
the 26 lowercase letters of the Latin alphabet
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
the 10 decimal digits
0 1 2 3 4 5 6 7 8 9
the following 29 graphic characters
! " # % & ' ( ) * + , - . / :
; < = > ? [ \ ] ^ _ { | } ~
the space character, and control characters representing
horizontal tab, vertical tab, and form feed. In both the
source and execution basic character sets, the value of each
character after 0 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 execution character set, there shall be
page 20 Environment
page 21
control characters representing alert, backspace, carriage
return, and new line. If any other characters are
encountered in a source file (except in a character
constant, a string literal, a header name, a comment, or a
preprocessing token that is never converted to a token), the
behavior is undefined.
[#4] The universal-character-name construct provides a way
to name other characters.
hex-quad:
hexadecimal-digit hexadecimal-digit
hexadecimal-digit hexadecimal-digit
universal-character-name:
\u hex-quad
\U hex-quad hex-quad
[#5] The character designated by the universal-character-
name \Unnnnnnnn is that character whose character short
identifier is nnnnnnnn specified by ISO/IEC 10646-1; the
character designated by the universal-character-name \unnnn
is that character whose character short identifier is
0000nnnn specified by ISO/IEC 10646-1.
Forward references: identifiers (6.1.2), character
constants (6.1.3.4), preprocessing directives (6.8), string
literals (6.1.4), comments (6.1.9), string (7.1.1).
5.2.1.1 Trigraph sequences
[#1] All occurrences in a source file of the following
sequences of three characters (called trigraph sequences12)
are replaced with the corresponding single character.
__________
12. The trigraph sequences enable the input of characters
that are not defined in the Invariant Code Set as
described in ISO/IEC 646:1991, which is a subset of the
seven-bit ASCII code set.
page 21 Environment
page 22
??= #
??( [
??/ \
??) ]
??' ^
??< {
??! |
??> }
??- ~
No other trigraph sequences exist. Each ? that does not
begin one of the trigraphs listed above is not changed.
Examples
[#2] The following source line
printf("Eh???/n");
becomes (after replacement of the trigraph sequence ??/)
printf("Eh?\n");
5.2.1.2 Multibyte characters
[#1] 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 single-byte characters defined in 5.2.1 shall be
present.
- The presence, meaning, and representation of any
additional members is locale-specific.
- A multibyte character 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.
page 22 Environment
page 23
- A byte with all bits zero shall not occur in the second
or subsequent bytes of a multibyte character.
[#2] For the source character set, the following shall hold:
- A comment, string literal, character constant, or
header name shall begin and end in the initial shift
state.
- A comment, string literal, character constant, or
header name shall consist of a sequence of valid
multibyte characters.
5.2.2 Character display semantics
[#1] 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 printable 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 is
unspecified.
[#2] Alphabetic escape sequences representing nongraphic
characters in the execution character set are intended to
produce actions on display devices as follows:
\a (alert) Produces an audible or visible alert. The active
position shall not be changed.
\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 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 is
page 23 Environment
page 24
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 is
unspecified.
[#3] 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.3.1.8), the
fputc function (7.13.7.3).
5.2.3 Signals and interrupts
[#1] 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
comprise the executable representation of a function) on a
per-invocation basis.
5.2.4 Environmental limits
[#1] Both the translation and execution environments
constrain the implementation of language translators and
libraries. The following summarizes the environmental
limits on a conforming implementation.
5.2.4.1 Translation limits
[#1] 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 compound statements, iteration
statements, and selection statements
__________
13. Implementations should avoid imposing fixed translation
limits whenever possible.
page 24 Environment
page 25
- 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
- 31 significant initial characters in an external
identifier
- 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 #included 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 levels of nested structure or union definitions in a
single struct-declaration-list
page 25 Environment
page 26
5.2.4.2 Numerical limits
[#1] A conforming implementation shall document all the
limits specified in this subclause, which shall be specified
in the headers <limits.h> and <float.h>.
5.2.4.2.1 Sizes of integer types <limits.h>
[#1] 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 (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
page 26 Environment
page 27
- 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
- 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
[#2] 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.14 The
value UCHAR_MAX+1 shall equal 2 raised to the power
CHAR_BIT.
5.2.4.2.2 Characteristics of floating types <float.h>
[#1] 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.15 The
__________
14. See 6.1.2.5.
15. The floating-point model is intended to clarify the
description of each floating-point characteristic and
page 27 Environment
page 28
following parameters are used to define the model for each
floating-point type:
s sign (_1)
b base or radix of exponent representation (an integer > 1)
e exponent (an integer between a minimum e and a maximum e )
p precision (the number of base-b digits inithe significand) max
f nonnegative integers less than b (the significand digits)
k
[#2] A normalized floating-point number x (f > 0 if x / 0)
is defined by the following model: 1
e p -k
x = s x b x R fk x b , emin < e < emax
k=1
[#3] Floating types might include values that are not
normalized floating-point numbers, for example subnormal
numbers (x / 0, e = e , f = 0), infinities, and NaNs. A
NaN is an encodingmisignifying Not-a-Number. A quiet NaN
propagates through almost every arithmetic operation without
raising an exception; a signaling NaN generally raises an
exception when occurring as an arithmetic operand.16
[#4] 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 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.
[#5] The rounding mode for floating-point addition is
characterized by the value of FLT_ROUNDS:17
____________________________________________________________
does not require the floating-point arithmetic of the
implementation to be identical.
16. IEC 559:1993 specifies quiet and signaling NaNs. For
implementations that do not support IEC 559:1993, the
terms quiet NaN and signaling NaN are intended to apply
to encodings with similar behavior.
17. Evaluation of FLT_ROUNDS correctly reflects any
execution-time change of rounding mode through the
function fesetround in <fenv.h>.
page 28 Environment
page 29
-1 indeterminable
0 toward zero
1 to nearest
2 toward positive infinity
3 toward negative infinity
All other values for FLT_ROUNDS characterize
implementation-defined rounding behavior.
[#6] 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 value of
FLT_EVAL_METHOD:18
-1 indeterminable;
0 evaluate all operations and constants just to the range
and precision of the type;
1 evaluate operations and constants of type float and
double to the range and precision of the double type,
evaluate long double operations and constants to the
range and precision of the long double type;
2 evaluate all operations and constants to the range and
precision of the long double type.
All other negative values for FLT_EVAL_METHOD characterize
implementation-defined behavior.
[#7] The values given in the following list shall be
replaced by implementation-defined expressions that shall be
equal or greater in magnitude (absolute value) to those
shown, with the same sign:
- radix of exponent representation, b
FLT_RADIX 2
__________
18. The evaluation method determines evaluation formats of
expressions involving all floating types, not just real
types. For example, if FLT_EVAL_METHOD is 1, then the
product of two float complex operands is represented in
the double complex format, and its parts are evaluated
to double.
page 29 Environment
page 30
- 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, q, such that any floating-
point number with q decimal digits can be rounded into
a floating-point number with p radix b digits and back
again without change to the q decimal digits,
(1 if b is a power of 10
| (p - 1) x log b | + |
| 10 | (0 otherwise
FLT_DIG 6
DBL_DIG 10
LDBL_DIG 10
- minimum negative integer such that FLT_RADIX raised to
that power minus 1 is a normalized floating-point
number, e
min
FLT_MIN_EXP
DBL_MIN_EXP
LDBL_MIN_EXP
- minimum negative integer such that 10 raised to that
power is in the range of normalized floating-point
| e -1 |
numbers, | log b min |
| 10 |
FLT_MIN_10_EXP -37
DBL_MIN_10_EXP -37
LDBL_MIN_10_EXP -37
- maximum integer such that FLT_RADIX raised to that
power minus 1 is a representable finite floating-point
number, e
max
FLT_MAX_EXP
DBL_MAX_EXP
LDBL_MAX_EXP
- maximum integer such that 10 raised to that power is in
the range of representable finite floating-point
| e |
numbers, | log ((1 - b-p) x b max) |
| 10 |
page 30 Environment
page 31
FLT_MAX_10_EXP +37
DBL_MAX_10_EXP +37
LDBL_MAX_10_EXP +37
[#8] The values given in the following list shall be
replaced by implementation-defined expressions with values
that shall be equal to or greater than those shown:
- max-pum reemaxentable finite floating-point number, (1
- b ) x b
FLT_MAX 1E+37
DBL_MAX 1E+37
LDBL_MAX 1E+37
[#9] The values given in the following list shall be
replaced by implementation-defined expressions with values
that shall be equal to or less than those shown:
- the difference between 1 and the least value greater
than 1 that1-ps representable in the given floating
point type, b
FLT_EPSILON 1E-5
DBL_EPSILON 1E-9
LDBL_EPSILON 1E-9
- eini-1m normalized positive floating-point number,
b min
FLT_MIN 1E-37
DBL_MIN 1E-37
LDBL_MIN 1E-37
Examples
[#10]
1. The following describes an artificial floating-point
representation that meets the minimum requirements of
this International Standard, and the appropriate
values in a <float.h> header for type float:
e 6 -k
x = s x 16 x R fk x 16 , -31 < e < +32
k=1
page 31 Environment
page 32
FLT_RADIX 16
FLT_MANT_DIG 6
FLT_EPSILON 9.53674316E-07F
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
2. The following describes floating-point representations
that also meet the requirements for single-precision
and double-precision normalized numbers in IEC 559,19
and the appropriate values in a <float.h> header for
types float and double:
e 24 -k
xf = s x 2 x R fk x 2 , -125 < e < +128
k=1
e 53 -k
xd = s x 2 x R fk x 2 , -1021 < e < +1024
k=1
__________
19. The floating-point model in that standard sums powers of
b from zero, so the values of the exponent limits are
one less than shown here.
page 32 Environment
page 33
FLT_RADIX 2
FLT_MANT_DIG 24
FLT_EPSILON 1.19209290E-07F // decimal constant
FLT_EPSILON 0X1P-23F // hex constant
FLT_DIG 6
FLT_MIN_EXP -125
FLT_MIN 1.17549435E-38F // decimal constant
FLT_MIN 0X1P-126F // hex constant
FLT_MIN_10_EXP -37
FLT_MAX_EXP +128
FLT_MAX 3.40282347E+38F // decimal constant
FLT_MAX 0X1.fffffeP127F // hex constant
FLT_MAX_10_EXP +38
DBL_MANT_DIG 53
DBL_EPSILON 2.2204460492503131E-16 // decimal constant
DBL_EPSILON 0X1P-52 // hex constant
DBL_DIG 15
DBL_MIN_EXP -1021
DBL_MIN 2.2250738585072014E-308 // decimal constant
DBL_MIN 0X1P-1022 // hex constant
DBL_MIN_10_EXP -307
DBL_MAX_EXP +1024
DBL_MAX 1.7976931348623157E+308 // decimal constant
DBL_MAX 0X1.ffffffffffffeP1023 // hex constant
DBL_MAX_10_EXP +308
Forward references: conditional inclusion (6.8.1).
page 33 Environment
page 34
6. Language
[#1] In the syntax notation used in the language clause
(clause 6), 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 suffix ``-opt,'' so that
{ expression-opt }
indicates an optional expression enclosed in braces.
6.1 Lexical elements
Syntax
[#1]
token:
keyword
identifier
constant
string-literal
operator
punctuator
preprocessing-token:
header-name
identifier
pp-number
character-constant
string-literal
operator
punctuator
each non-white-space character that cannot be one of the above
Constraints
[#2] Each preprocessing token that is converted to a token
shall have the lexical form of a keyword, an identifier, a
constant, a string literal, an operator, or a punctuator.
page 34 Language
page 35
Semantics
[#3] A token is the minimal lexical element of the language
in translation phases 7 and 8. The categories of tokens
are: keywords, identifiers, constants, string literals,
operators, and punctuators. A preprocessing token is the
minimal lexical element of the language in translation
phases 3 through 6. The categories of preprocessing token
are: header names, identifiers, preprocessing numbers,
character constants, string literals, operators,
punctuators, and 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.8, 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 constant or string literal.
[#4] 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.
[#5] A header name preprocessing token is only recognized
within a #include preprocessing directive, and within such a
directive, a sequence of characters that could be either a
header name or a string literal is recognized as the former.
Examples
1. The program fragment 1Ex is parsed as a preprocessing
number token (one that is not a valid floating or
integer constant token), even though a parse as the
pair of preprocessing tokens 1 and Ex might 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 constant token), whether or not E is a
macro name.
2. The program fragment x+++++y is parsed as x+++++y,
which violates a constraint on increment operators,
even though the parse x+++++y might yield a correct
expression.
page 35 Language
page 36
Forward references: character constants (6.1.3.4), comments
(6.1.9), expressions (6.3), floating constants (6.1.3.1),
header names (6.1.7), macro replacement (6.8.3), postfix
increment and decrement operators (6.3.2.4), prefix
increment and decrement operators (6.3.3.1), preprocessing
directives (6.8), preprocessing numbers (6.1.8), string
literals (6.1.4).
6.1.1 Keywords
Syntax
[#1]
keyword: one of
auto break case char
complex const continue default
do double else enum
extern float for goto
if imaginary inline int
long register restrict return
short signed sizeof static
struct switch typedef union
unsigned void volatile while
Semantics
[#2] The token complex is reserved in translation units
where the header <complex.h> is included; the token
imaginary is reserved in translation units where both the
header <complex.h> is included and the macro _Imaginary_I is
defined; all other keyword tokens are reserved in all
translation units. When reserved, the above tokens
(entirely in lowercase) are keywords (in translation phases
7 and 8), and shall not be used otherwise. When the token
complex or imaginary is reserved, its use prior to the first
inclusion of the header <complex.h> results in undefined
behavior.
page 36 Language
page 37
6.1.2 Identifiers
Syntax
[#1]
identifier:
nondigit
identifier nondigit
identifier digit
nondigit: one of
universal-character-name
_ 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
Description
[#2] An identifier is a sequence of nondigit characters
(including the underscore _ and the lowercase and uppercase
letters) and digits. Each universal-character-name in an
identifier shall designate a character whose encoding in ISO
10646-1 falls into one of the ranges specified in Annex
H.20 The first character shall be a nondigit character.
Semantics
[#3] An identifier can denote an object, a function, or one
of the following entities that will be described later: 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
__________
20. On systems in which linkers cannot accept extended
characters, an encoding of the universal-character-name
may be used in forming valid external identifiers. For
example, some otherwise unused character or sequence of
characters may be used to encode the \u in a universal-
character-name. Extended characters may produce a long
external identifier.
page 37 Language
page 38
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.
[#4] There is no specific limit on the maximum length of an
identifier.
[#5] 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.
Implementation limits
[#6] The implementation shall treat at least the first 63
characters of an internal name (a macro name or an
identifier that does not have external linkage) as
significant. The implementation may further restrict the
significance of an external name (an identifier that has
external linkage) to 31 characters. In both external and
internal names, lower-case and upper-case letters are
different. The number of significant characters in an
identifier is implementation-defined.
[#7] Any identifiers that differ in a significant character
are different identifiers. If two identifiers differ in a
nonsignificant character, the behavior is undefined.
Forward references: linkages of identifiers (6.1.2.2),
macro replacement (6.8.3).
6.1.2.1 Scopes of identifiers
[#1] 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 non-overlapping 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 that declares the types of its
parameters.)
[#2] 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). Label names shall be unique within a
function.
page 38 Language
page 39
[#3] 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 } that closes the
associated block. If the declarator or type specifier that
declares the identifier appears within the list of parameter
declarations in a function prototype (not part of a function
definition), the identifier has function prototype scope,
which terminates at the end of the function declarator. If
an identifier designates two different entities in the same
name space, the scopes might overlap. If so, the scope of
one entity (the inner scope) will be a strict subset of the
scope of the other entity (the outer scope). Within the
inner scope, the identifier designates the entity declared
in the inner scope; the entity declared in the outer scope
is hidden (and not visible) within the inner scope.
[#4] Unless explicitly stated otherwise, where this
International Standard uses the term identifier to refer to
some 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.
[#5] Two identifiers have the same scope if and only if
their scopes terminate at the same point.
[#6] 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. Any other
identifier has scope that begins just after the completion
of its declarator.
Forward references: compound statement, or block (6.6.2),
declarations (6.5), enumeration specifiers (6.5.2.2),
function calls (6.3.2.2), function declarators (including
prototypes) (6.5.5.3), function definitions (6.7.1), the
goto statement (6.6.6.1), labeled statements (6.6.1), name
spaces of identifiers (6.1.2.3), scope of macro definitions
(6.8.3.5), source file inclusion (6.8.2), tags (6.5.2.3),
type specifiers (6.5.2).
page 39 Language
page 40
6.1.2.2 Linkages of identifiers
[#1] 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.
[#2] In the set of translation units and libraries that
constitutes an entire program, each instance of a particular
identifier with external linkage denotes the same object or
function. Within one translation unit, each instance of an
identifier with internal linkage denotes the same object or
function. Identifiers with no linkage denote unique
entities.
[#3] If the declaration of a file scope identifier for an
object or a function contains the storage-class specifier
static, the identifier has internal linkage.21
[#4] For an identifier declared with the storage-class
specifier extern in a scope in which a prior declaration of
that identifier is visible,22 if the prior declaration
specifies internal or external linkage, the linkage of the
identifier at the later declaration becomes 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.
[#5] 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 for
an object has file scope and no storage-class specifier, its
linkage is external.
[#6] 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.
__________
21. A function declaration can contain the storage-class
specifier static only if it is at file scope; see 6.5.1.
22. As specified in 6.1.2.1, the later declaration might
hide the prior declaration.
page 40 Language
page 41
[#7] If, within a translation unit, the same identifier
appears with both internal and external linkage, the
behavior is undefined.
Forward references: compound statement, or block (6.6.2),
declarations (6.5), expressions (6.3), external definitions
(6.7).
6.1.2.3 Name spaces of identifiers
[#1] 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 any23 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);
- all other identifiers, called ordinary identifiers
(declared in ordinary declarators or as enumeration
constants).
Forward references: enumeration specifiers (6.5.2.2),
labeled statements (6.6.1), structure and union specifiers
(6.5.2.1), structure and union members (6.3.2.3), tags
(6.5.2.3).
__________
23. There is only one name space for tags even though three
are possible.
page 41 Language
page 42
6.1.2.4 Storage durations of objects
[#1] An object has a storage duration that determines its
lifetime. There are three storage durations: static,
automatic, and allocated. Allocated storage is described in
7.14.3.
[#2] An object whose identifier is declared with external or
internal linkage, or with the storage-class specifier static
has static storage duration. For such an object, storage is
reserved and its stored value is initialized only once,
prior to program startup. The object exists, has a constant
address, and retains its last-stored value throughout the
execution of the entire program.24
[#3] An object whose identifier is declared with no linkage
and without the storage-class specifier static has automatic
storage duration. Storage is guaranteed to be reserved for
a new instance of such an object on each normal entry into
the block with which it is associated. If the block with
which the object is associated is entered by a jump from
outside the block to a labeled statement in the block or in
an enclosed block, then storage is guaranteed to be reserved
provided the object does not have a variable length array
type. If the object is variably modified and the block is
entered by a jump to a labeled statement, then the behavior
is undefined. If an initialization is specified for the
value stored in the object, it is performed on each normal
entry, but not if the block is entered by a jump to a
labeled statement beyond the declaration. A backwards jump
might cause the initializer to be evaluated more than once;
if so, a new value will be stored each time. Storage for
the object is no longer guaranteed to be reserved when
execution of the block ends in any way. (Entering an
enclosed block suspends but does not end execution of the
enclosing block. Calling a function suspends but does not
end execution of the block containing the call.) The value
of a pointer that referred to an object with automatic
storage duration that is no longer guaranteed to be reserved
__________
24. The term constant address means that two pointers to the
object constructed at possibly different times will
compare equal. The address may be different during two
different executions of the same program.
In the case of a volatile object, the last store may not
be explicit in the program.
page 42 Language
page 43
is indeterminate. During execution of the associated block,
the object has a constant address.
Forward references: compound statement, or block (6.6.2),
function calls (6.3.2.2), declarators (6.5.5), array
declarators (6.5.5.2), initialization (6.5.8).
6.1.2.5 Types
[#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), function
types (types that describe functions), and incomplete types
(types that describe objects but lack information needed to
determine their sizes).
[#2] An object declared as type char is large enough to
store any member of the basic execution character set. If a
member of the required source character set enumerated in
5.2.1 is stored in a char object, its value is guaranteed to
be positive. 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.
[#3] There are five standard signed integer types,
designated as signed char, short int, int, long int, and
long long int. (These and other types may be designated in
several additional ways, as described in 6.5.2.) There may
also be implementation-defined extended signed integer
types.25 The standard and extended signed integer types are
collectively called just signed integer types.26
[#4] 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
__________
25. Implementation-defined keywords must have the form of an
identifier reserved for any use as described in 7.1.3.
26. Therefore, any statement in this Standard about signed
integer types also applies to the extended signed
integer types.
page 43 Language
page 44
contain any value in the range INT_MIN to INT_MAX as defined
in the header <limits.h>).
[#5] 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 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.
[#6] The extended signed integer types and extended unsigned
integer types are collectively called the extended integer
types.
[#7] For any two types with the same signedness and
different integer conversion rank, the range of values of
the type with smaller integer conversion rank is a subrange
of the values of the other type.
[#8] 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.27 A computation involving unsigned operands
can never overflow, because a result that cannot be
represented by the resulting unsigned integer type is
reduced modulo the number that is one greater than the
largest value that can be represented by the resulting
unsigned integer type.
[#9] There are three real 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.
[#10] There are three complex types, designated as float
complex, double complex, and long double complex.28 The
__________
27. The same representation and alignment requirements are
meant to imply interchangeability as arguments to
functions, return values from functions, and members of
unions.
28. A specification for imaginary types is in informative
Annex G.
page 44 Language
page 45
real floating and complex types are collectively called the
floating types.
[#11] 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.
[#12] 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.
[#13] The type char, the signed and unsigned integer types,
and the floating types are collectively called the basic
types. Even if the implementation defines two or more basic
types to have the same representation, they are nevertheless
different types.29
[#14] 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 one of signed char and
unsigned char.30
[#15] An enumeration comprises a set of named integer
constant values. Each distinct enumeration constitutes a
different enumerated type.
[#16] The void type comprises an empty set of values; it is
an incomplete type that cannot be completed.
__________
29. An implementation may define new keywords that provide
alternative ways to designate a basic (or any other)
type. An alternate way to designed a basic type does
not violate the requirement that all basic types be
different. Implementation-defined keywords must have
the form of an identifier reserved for any use as
described in 7.1.3.
30. CHAR_MIN, defined in <limits.h>, will have one of the
values 0 or SCHAR_MIN, and this can be used to
distinguish the two options. Irrespective of the choice
made, char is a separate type from the other two, and it
not compatible with either.
page 45 Language
page 46
[#17] Any number of derived types can be constructed from
the object, function, and incomplete types, as follows:
- An array type describes a contiguously allocated
nonempty set of objects with a particular member object
type, called the element type.31 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, 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.''
- A pointer type may be derived from a function type, an
object type, or an incomplete type, called the
referenced type. A pointer type describes an object
whose value provides a reference to an entity of the
referenced type. A pointer type derived from the
referenced type T is sometimes called ``pointer to T.''
The construction of a pointer type from a referenced
type is called ``pointer type derivation.''
[#18] These methods of constructing derived types can be
applied recursively.
[#19] The type char, the signed and unsigned integer types,
and the enumerated types are collectively called integer
__________
31. Since object types do not include incomplete types, an
array of incomplete type cannot be constructed.
page 46 Language
page 47
types. The integer and real floating types are collectively
called real types.
[#20] Integer and floating types are collectively called
arithmetic types. Arithmetic types and pointer types are
collectively called scalar types. Array and structure types
are collectively called aggregate types.32
[#21] Each arithmetic type belongs to one type-domain. The
real type-domain comprises the real types. The complex
type-domain comprises the complex types.
[#22] 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.5.2.3) 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.
[#23] 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.
[#24] A type is characterized by its type category, which is
either the outermost derivation of a derived type (as noted
above in the construction of derived types), or the type
itself if the type consists of no derived types.
[#25] Any type so far mentioned is an unqualified type.
Each unqualified type has several qualified versions of its
type,33 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.27 A derived
type is not qualified by the qualifiers (if any) of the type
from which it is derived.
__________
32. Note that aggregate type does not include union type
because an object with union type can only contain one
member at a time.
33. See 6.5.3 regarding qualified array and function types.
page 47 Language
page 48
[#26] 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.27 All pointers to structure types
shall