ISO/IEC 9899:1999

Programming languages - C

Langages de programmation — C

General Information

• Status: Withdrawn
• Publication Date: 15-Dec-1999
• Withdrawal Date: 15-Dec-1999
• ICS: 35.060 - Languages used in information technology
• Technical Committee: ISO/IEC JTC 1/SC 22 - Programming languages, their environments and system software interfaces
• Drafting Committee: ISO/IEC JTC 1/SC 22/WG 14 - C
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 08-Dec-2011
• Completion Date: 30-Oct-2025

Relations

• Revised: ISO/IEC 9899:2011 - Information technology - Programming languages - C
• Effective Date: 04-Dec-2010
• Revises: ISO/IEC 9899:1990 - Programming languages - C
• Effective Date: 15-Apr-2008
• Revises: ISO/IEC 9899:1990/Cor 1:1994 - Programming languages - C - Technical Corrigendum 1
• Effective Date: 15-Apr-2008
• Revises: ISO/IEC 9899:1990/Amd 1:1995 - Programming languages - C - Amendment 1: C Integrity
• Effective Date: 15-Apr-2008
• Revises: ISO/IEC 9899:1990/Cor 2:1996 - Programming languages - C - Technical Corrigendum 2
• Effective Date: 15-Apr-2008

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 9899
Second edition
1999-12-01
Programming languages — C
Langages de programmation — C
Reference number
©
ISO/IEC 1999
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but shall not
be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In downloading this
file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat accepts no liability in this
area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation parameters
were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the unlikely event
that a problem relating to it is found, please inform the Central Secretariat at the address given below.
© ISO/IEC 1999
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic
or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or ISO's member body
in the country of the requester.
ISO copyright office
Case postale 56 � CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 734 10 79
E-mail [e-mail]
Web www.iso.ch
Printed in Switzerland
ii © ISO/IEC 1999 – All rights reserved

©ISO/IEC ISO/IEC 9899:1999 (E)
Contents
Foreword . xi
Introduction . xiv
1. Scope . 1
2. Normative references . 2
3. Terms, definitions, and symbols . 3
4. Conformance . 7
5. Environment . 9
5.1 Conceptualmodels . 9
5.1.1 Translation environment . 9
5.1.2 Execution environments . 11
5.2 Environmental considerations . 17
5.2.1 Charactersets . 17
5.2.2 Characterdisplay semantics . 19
5.2.3 Signalsand interrupts . 20
5.2.4 Environmental limits . 20
6. Language . 29
6.1 Notation . 29
6.2 Concepts . 29
6.2.1 Scopesof identifiers . 29
6.2.2 Linkagesof identifiers . 30
6.2.3 Name spaces of identifiers . 31
6.2.4 Storage durations of objects . 32
6.2.5 Types . 33
6.2.6 Representationsof types . 37
6.2.7 Compatible type and composite type . 40
6.3 Conversions . 42
6.3.1 Arithmeticoperands . 42
6.3.2 Otheroperands . 46
6.4 Lexical elements . 49
6.4.1 Keywords . 50
6.4.2 Identifiers . 51
6.4.3 Universal character names . 53
6.4.4 Constants . 54
6.4.5 Stringliterals . 62
6.4.6 Punctuators . 63
6.4.7 Headernames . 64
6.4.8 Preprocessingnumbers . 65
6.4.9 Comments . 66
6.5 Expressions . 67
Contents iii
6.5.1 Primaryexpressions . 69
6.5.2 Postfixoperators . 69
6.5.3 Unaryoperators . 78
6.5.4 Castoperators . 81
6.5.5 Multiplicative operators . 82
6.5.6 Additive operators . 82
6.5.7 Bitwiseshift operators . 84
6.5.8 Relationaloperators . 85
6.5.9 Equalityoperators . 86
AND operator . 87
6.5.10 Bitwise
6.5.11 Bitwiseexclusive OR operator . 88
6.5.12 Bitwiseinclusive OR operator . 88
6.5.13 Logical AND operator . 89
6.5.14 Logical OR operator . 89
6.5.15 Conditionaloperator . 90
6.5.16 Assignmentoperators . 91
6.5.17 Commaoperator . 94
6.6 Constantexpressions . 95
6.7 Declarations . 97
6.7.1 Storage-classspecifiers . 98
6.7.2 Type specifiers . 99
6.7.3 Type qualifiers . 108
6.7.4 Functionspecifiers . 112
6.7.5 Declarators . 114
6.7.6 Type names . 122
6.7.7 Type definitions . 123
6.7.8 Initialization . 125
6.8 Statementsand blocks . 131
6.8.1 Labeledstatements . 131
6.8.2 Compoundstatement . 132
6.8.3 Expression and null statements . 132
6.8.4 Selectionstatements . 133
6.8.5 Iterationstatements . 135
6.8.6 Jumpstatements . 136
6.9 Externaldefinitions . 140
6.9.1 Functiondefinitions . 141
6.9.2 Externalobject definitions . 143
6.10 Preprocessingdirectives . 145
6.10.1 Conditionalinclusion . 147
6.10.2 Sourcefile inclusion . 149
6.10.3 Macroreplacement . 151
6.10.4 Linecontrol . 158
6.10.5 Errordirective . 159
6.10.6 Pragmadirective . 159
iv Contents
©ISO/IEC ISO/IEC 9899:1999 (E)
6.10.7 Nulldirective . 160
6.10.8 Predefinedmacro names . 160
6.10.9 Pragmaoperator . 161
6.11 Futurelanguage directions . 163
6.11.1 Floatingtypes . 163
6.11.2 Linkagesof identifiers . 163
6.11.3 Externalnames . 163
6.11.4 Characterescape sequences . 163
6.11.5 Storage-classspecifiers . 163
6.11.6 Functiondeclarators . 163
6.11.7 Functiondefinitions . 163
6.11.8 Pragmadirectives . 163
6.11.9 Predefinedmacro names . 163
7. Library . 164
7.1 Introduction . 164
7.1.1 Definitionsof terms . 164
7.1.2 Standardheaders . 165
7.1.3 Reserved identifiers . 166
7.1.4 Use of library functions . 166
7.2 Diagnostics . 169
7.2.1 Programdiagnostics . 169
7.3 Complexarithmetic . 170
7.3.1 Introduction . 170
7.3.2 Conventions . 171
7.3.3 Branchcuts . 171
7.3.4 TheCX_LIMITED_RANGE pragma . 171
7.3.5 Trigonometric functions . 172
7.3.6 Hyperbolicfunctions . 174
7.3.7 Exponential and logarithmic functions . 176
7.3.8 Power and absolute-value functions . 177
7.3.9 Manipulationfunctions . 178
7.4 Characterhandling . 181
7.4.1 Characterclassification functions . 181
7.4.2 Character case mapping functions . 184
7.5 Errors . 186
7.6 Floating-pointenvironment . 187
7.6.1 TheFENV_ACCESS pragma . 189
7.6.2 Floating-pointexceptions . 190
7.6.3 Rounding . 192
7.6.4 Environment . 194
7.7 Characteristics of floating types . 196
7.8 Format conversion of integer types . 197
7.8.1 Macros for format specifiers . 197
7.8.2 Functions for greatest-width integer types . 198
Contents v
7.9 Alternative spellings . 201
7.10 Sizes of integer types . 202
7.11 Localization . 203
7.11.1 Localecontrol . 204
7.11.2 Numeric formatting convention inquiry . 205
7.12 Mathematics . 211
7.12.1 Treatment of error conditions . 213
7.12.2 TheFP_CONTRACT pragma . 214
7.12.3 Classificationmacros . 215
7.12.4 Trigonometric functions . 217
7.12.5 Hyperbolicfunctions . 220
7.12.6 Exponential and logarithmic functions . 222
7.12.7 Power and absolute-value functions . 227
7.12.8 Error and gamma functions . 229
7.12.9 Nearestinteger functions . 230
7.12.10 Remainderfunctions . 234
7.12.11 Manipulationfunctions . 235
7.12.12 Maximum, minimum, and positive difference functions . 237
7.12.13 Floatingmultiply-add . 238
7.12.14 Comparisonmacros . 239
7.13 Nonlocaljumps . 242
7.13.1 Save calling environment . 242
7.13.2 Restorecalling environment . 243
7.14 Signalhandling . 245
7.14.1 Specifysignal handling . 246
7.14.2 Sendsignal . 247
7.15 Variable arguments . 248
7.15.1 Variable argument list access macros . 248
7.16 Boolean type and values . 252
7.17 Commondefinitions . 253
7.18 Integer types . 254
7.18.1 Integer types . 254
7.18.2 Limits of specified-width integer types . 256
7.18.3 Limits of other integer types . 258
7.18.4 Macros for integer constants . 259
7.19 Input/output . 261
7.19.1 Introduction . 261
7.19.2 Streams . 263
7.19.3 Files . 265
7.19.4 Operationson files . 267
7.19.5 Fileaccess functions . 269
7.19.6 Formatted input/output functions . 273
7.19.7 Characterinput/output functions . 294
7.19.8 Directinput/output functions . 299
vi Contents
©ISO/IEC ISO/IEC 9899:1999 (E)
7.19.9 Filepositioning functions . 300
7.19.10 Error-handling functions . 303
7.20 Generalutilities . 305
7.20.1 Numericconversion functions . 306
7.20.2 Pseudo-random sequence generation functions . 311
7.20.3 Memorymanagement functions . 312
7.20.4 Communication with the environment . 314
7.20.5 Searching and sorting utilities . 317
7.20.6 Integer arithmetic functions . 319
7.20.7 Multibyte/wide character conversion functions . 320
7.20.8 Multibyte/wide string conversion functions . 322
7.21 Stringhandling . 324
7.21.1 Stringfunction conventions . 324
7.21.2 Copying functions . 324
7.21.3 Concatenationfunctions . 326
7.21.4 Comparisonfunctions . 327
7.21.5 Searchfunctions . 329
7.21.6 Miscellaneousfunctions . 332
7.22 Type-generic math . 334
7.23 Dateand time . 337
7.23.1 Componentsof time . 337
7.23.2 Time manipulation functions . 338
7.23.3 Time conversion functions . 340
7.24 Extended multibyte and wide character utilities . 347
7.24.1 Introduction . 347
7.24.2 Formatted wide character input/output functions . 348
7.24.3 Wide character input/output functions . 366
7.24.4 General wide string utilities . 370
7.24.5 Wide character time conversion functions . 384
7.24.6 Extended multibyte/wide character conversion utilities . 385
7.25 Wide character classification and mapping utilities . 392
7.25.1 Introduction . 392
7.25.2 Wide character classification utilities . 393
7.25.3 Wide character case mapping utilities . 398
7.26 Futurelibrary directions . 400
7.26.1 Complexarithmetic . 400
7.26.2 Characterhandling . 400
7.26.3 Errors . 400
7.26.4 Format conversion of integer types . 400
7.26.5 Localization . 400
7.26.6 Signalhandling . 400
7.26.7 Boolean type and values . 400
7.26.8 Integer types . 400
7.26.9 Input/output . 401
Contents vii
7.26.10 Generalutilities . 401
7.26.11 Stringhandling . 401
7.26.12 Extended multibyte and wide character utilities
. 401
7.26.13 Wide character classification and mapping utilities
. 401
Annex A (informative) Language syntax summary . 402
A.1 Lexical grammar . 402
A.2 Phrasestructure grammar . 408
A.3 Preprocessingdirectives . 415
Annex B (informative) Library summary . 417
B.1 Diagnostics . 417
B.2 Complex . 417
B.3 Characterhandling . 419
B.4 Errors . 419
B.5 Floating-pointenvironment . 419
B.6 Characteristics of floating types . 420
B.7 Format conversion of integer types . 420
B.8 Alternative spellings . 421
B.9 Sizes of integer types . 421
B.10 Localization . 421
B.11 Mathematics . 421
B.12 Nonlocaljumps . 426
B.13 Signalhandling . 426
B.14 Variable arguments . 426
B.15 Boolean type and values . 426
B.16 Commondefinitions . 427
B.17 Integer types . 427
B.18 Input/output . 427
B.19 Generalutilities . 429
B.20 Stringhandling . 431
B.21 Type-generic math . 432
B.22 Dateand time . 432
B.23 Extended multibyte/wide character utilities . 433
B.24 Wide character classification and mapping utilities . 435
Annex C (informative) Sequence points . 437
Annex D (normative) Universal character names for identifiers . 438
Annex E (informative) Implementation limits . 440
Annex F (normative) IEC 60559 floating-point arithmetic . 442
F.1 Introduction . 442
F.2 Types . 442
F.3 Operators and functions . 443
viii Contents
©ISO/IEC ISO/IEC 9899:1999 (E)
F.4 Floating to integer conversion . 445
F.5 Binary-decimal conversion . 445
F.6 Contracted expressions . 446
F.7 Floating-point environment . 446
F.8 Optimization . 449
F.9 Mathematics . 452
Annex G (informative) IEC 60559-compatible complex arithmetic . 465
G.1 Introduction . 465
G.2 Types . 465
G.3 Conventions . 465
G.4 Conversions . 466
G.5 Binaryoperators . 466
G.6 Complexarithmetic . 470
G.7 Type-generic math . 478
Annex H (informative) Language independent arithmetic . 479
H.1 Introduction . 479
H.2 Types . 479
H.3 Notification . 483
Annex I (informative) Common warnings . 485
Annex J (informative) Portability issues . 487
J.1 Unspecifiedbehavior . 487
J.2 Undefinedbehavior . 490
J.3 Implementation-definedbehavior . 503
J.4 Locale-specificbehavior . 510
J.5 Commonextensions . 511
Bibliography . 514
Index . 517
Contents ix
x Contents
©ISO/IEC ISO/IEC 9899:1999 (E)
Foreword
1 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.
2 International Standards are drafted in accordance with the rules given in the ISO/IEC
Directives, Part 3.
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.
4 International Standard ISO/IEC9899 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 (WG14) maintains a site on the World Wide Web at
http://www.dkuug.dk/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.
5 This second edition cancels and replaces the first edition, ISO/IEC9899: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 (originally specified
in AMD1)
— wide character library support in and (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
— type-generic math macros in
Foreword xi
— thelong long int type and library functions
— increased minimum translation limits
— additional floating-point characteristics in
— remove implicitint
— reliable integer division
— universal character names (\u and\U)
— extended identifiers
— hexadecimal floating-point constants and %a and %A printf/scanf conversion
specifiers
— compound literals
— designated initializers
— // comments
— extended integer types and library functions in and
— remove implicit function declaration
— preprocessor arithmetic done inintmax_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
— thevscanf family of functions in and
— additional math library functions in
— floating-point environment access in
— IEC 60559 (also known as IEC 559 or IEEE arithmetic) support
— trailing comma allowed inenum declaration
— %lf conversion specifier allowed inprintf
— inline functions
— thesnprintf family of functions in
— boolean type in
— idempotent type qualifiers
— empty macro arguments
xii Foreword
©ISO/IEC ISO/IEC 9899:1999 (E)
— new struct type compatibility rules (tag compatibility)
— additional predefined macro names
— _Pragma preprocessing operator
— standard pragmas
— __func_ _ predefined identifier
— VA_COPY macro
— additionalstrftime conversion specifiers
— LIA compatibility annex
— deprecateungetc 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)
6 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
1 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.
2 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.
3 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).
4 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.
5 The language clause (clause 6) is derived from ‘‘The C Reference Manual’’.
6 The library clause (clause 7) is based on the 1984 /usr/group Standard.
xiv Introduction
INTERNATIONAL STANDARD ©ISO/IEC ISO/IEC 9899:1999 (E)
Programming languages — C
1. Scope
1 This International Standard specifies the form and establishes the interpretation of
1)
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.
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;
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.
§1 General 1
— the size or complexity of a program and its data that will exceed the capacity of any
specific data-processing system or the capacity of a particular processor;
— all minimal requirements of a data-processing system that is capable of supporting a
conforming implementation.
2. Normative references
1 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.
2 ISO 31−11:1992, Quantities and units — Part 11: Mathematical signs and symbols for
use in the physical sciences and technology.
3 ISO/IEC 646, Information technology — ISO 7-bit coded character set for information
interchange.
4 ISO/IEC 2382−1:1993, Information technology — Vocabulary — Part 1: Fundamental
terms.
5 ISO 4217, Codes for the representation of currencies and funds.
6 ISO 8601, Data elements and interchange formats — Information interchange —
Representation of dates and times.
7 ISO/IEC 10646 (all parts), Information technology — Universal Multiple-Octet Coded
Character Set (UCS).
8 IEC 60559:1989, Binary floating-point arithmetic for microprocessor systems (previously
designated IEC 559:1989).
2 General §2
©ISO/IEC ISO/IEC 9899:1999 (E)
3. Terms, definitions, and symbols
1 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
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
1 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
1 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
1 behavior
external appearance or action
3.4.1
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
1 locale-specific behavior
behavior that depends on local conventions of nationality, culture, and language that each
implementation documents
§3.4.2 General 3
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
1 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
1 unspecified behavior
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
1 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
1 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
1 character
〈abstract〉 member of a set of elements used for the organization, control, or
representation of data
3.7.1
1 character
single-byte character
〈C〉 bit representation that fits in a byte
4 General §3.7.1
©ISO/IEC ISO/IEC 9899:1999 (E)
3.7.2
1 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
1 wide character
bit representation that fits in an object of type wchar_t, capable of representing any
character in the current locale
3.8
1 constraint
restriction, either syntactic or semantic, by which the exposition of language elements is
to be interpreted
3.9
1 correctly rounded result
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.10
1 diagnostic message
message belonging to an implementation-defined subset of the implementation’s message
output
3.11
1 forward reference
reference to a later subclause of this International Standard that contains additional
information relevant to this subclause
3.12
1 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
1 implementation limit
restriction imposed upon programs by the implementation
3.14
1 object
region of data storage in the execution environment, the contents of which can represent
values
§3.14 General 5
NOTE When referenced, an object may be interpreted as having a particular type; see 6.3.2.1.
3.15
1 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
1 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
1 value
precise meaning of the contents of an object when interpreted as having a specific type
3.17.1
1 implementation-defined value
unspecified value where each implementation documents how the choice is made
3.17.2
1 indeterminate value
either an unspecified value or a trap representation
3.17.3
1 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
1 x
 
ceiling of x: the least integer greater than or equal to x
EXAMPLE 2. 4 is 3, −2. 4 is −2.
   
3.19
1 x
 
floor of x: the greatest integer less than or equal to x
EXAMPLE 2. 4 is 2, −2. 4 is −3.
   
6 General §3.19
©ISO/IEC ISO/IEC 9899:1999 (E)
4. Conformance
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 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 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.
4 The implementation shall not successfully translate a preprocessing translation unit
containing a #error preprocessing directive unless it is part of a group skipped by
conditional inclusion.
5A strictly conforming program shall use only those features of the language and library
2)
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.
6 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 ,
, , , , , and
. A conforming implementation may have extensions (including additional
library functions), provided they do not alter the behavior of any strictly conforming
3)
program.
2) 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
3) This implies that a conforming implementation reserves no identifiers other than those explicitly
reserved in this International Standard.
§4 General 7
4)
7A conforming program is one that is acceptable to a conforming implementation.
8 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 (7.7), alternative spellings
(7.9), sizes of integer types (7.10), variable arguments
(7.15), boolean type and values (7.16), common definitions
(7.17), integer types (7.18).
4) Strictly conforming programs are intended to be maximally portable among conforming
implementations. Conforming programs may depend upon nonportable features of a conforming
implementation.
8 General §4
©ISO/IEC ISO/IEC 9899:1999 (E)
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 this clause, only a few of many possible forward references
have been noted.
5.1 Conceptualmodels
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, (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
1 The precedence among the syntax rules of translation is specified by the following
5)
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.
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
5) Implementations shall behave as if these separate phases occur, even though many are typically folded
together in practice.
§5.1.1.2 Environment 9
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.
6)
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-
7)
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).
6) 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.
7) An implementation need not convert all non-corresponding source characters to the same execution
character.
10 Environment §5.1.1.2
©ISO/IEC ISO/IEC 9899:1999 (E)
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
8)
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 Executionenvironments
1 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
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, other than the minimal set required by clause 4, are implementation-defined.
2 The effect of program termination in a freestanding environment is implementation-
defined.
5.1.2.2 Hostedenvironment
1 A hosted environment need not be provided, but shall conform to the following
specifications if present.
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.
§5.1.2.2 Environment 11
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 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[]) { /* . */ }
9)
or equivalent; or in some other implementation-defined manner.
2 If they are declared, the parameters to the main function shall obey the following
constraints:
— The value ofargc 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 t
...