Programming languages — C

Langages de programmation — C

General Information

Status
Withdrawn
Publication Date
19-Dec-1990
Withdrawal Date
19-Dec-1990
Current Stage
9599 - Withdrawal of International Standard
Completion Date
16-Dec-1999
Ref Project

Relations

Effective Date
15-Apr-2008

Buy Standard

Standard
ISO/IEC 9899:1990 - Programming languages -- C
English language
219 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (Sample)

INTERNATIONAL
ISOIIEC
STANDARD
9899
First edition
1990-12-15
Programming languages - C
Langages de programmation - C
w
E
-
-
=
= E
=
=
=
=
= =
= z
z
2
= =
=
3
=.
s
= =
-
C Reference number
E Z
E-
-
ISOAEC 9899 : 1990 (El

---------------------- Page: 1 ----------------------
ISO/IEC 9899: 1990 (E)
Contents
1
1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
2 Normative references . . . . . . . . . . . . . . . . . . . . . .
2
3 Definitions and conventions . . . . . . . . . . . . . . . . . . . .
3
4 Compliance . . . . . . . . . . . . . . . . . . . . . . . . .
5
.........................
5 Environment
5
.....................
5.1 Conceptual models
5
.................
51.1 Translation environment
6
.................
51.2 Execution environments
10
..................
5.2 Environmental considerations
10
....................
5.2.1 Character sets
12
................
5.2.2 Character display semantics
12
..................
5.2.3 Signals and interrupts
12
..................
5.2.4 Environmental limits
18
..........................
6 Language
18
......................
6.1 Lexical elements
19
.....................
6.1.1 Keywords
19
.....................
6.1.2 Identifiers
25
....................
6.1.3 Constants
30
.....................
6.1.4 String literals
31
6.1.5 Operators .
32
6.1.6 Punctuators .
32
6.1.7 Header names .
33
6.1.8 Preprocessing numbers .
33
.....................
6.1.9 Comments
34
.......................
6.2 Conversions
34
..................
6.2.1 Arithmetic operands
36
....................
6.2.2 Other operands
38
.......................
6.3 Expressions
39
..................
6.3.1 Primary expressions
39
...................
6.3.2 Postfix operators
43
....................
Unary operators
6.3.3
45
Cast operators .
6.3.4
46
.................
6.3.5 Multiplicative operators
46
...................
6.3.6 Additive operators
48
..................
6.3.7 Bitwise shift operators
48
..................
6.3.8 Relational operators
49
...................
Equality operators
6.3.9
50
..................
Bitwise AND operator
6.3.10
50
...............
6.3.11 Bitwise exclusive OR operator
50
...............
6.3.12 Bitwise inclusive OR operator
51
..................
6.3.13 Logical AND operator
51
..................
6.3.14 Logical OR operator
51
..................
6.3.15 Conditional operator
0 ISO/IEC 1990
All rights reserved. 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 the publisher.
ISO/IEC Copyright Office l Case postale 56 l CH-1211 Geneve 20 l Switzerland
Printed in Switzerland
ii

---------------------- Page: 2 ----------------------
ISO/IEC 9899: 1990 (E)
. . . . . . . . 53
6.3.16 Assignment operators . . . . . . . . . .
. . . . . 54
6.3.17 Comma operator . . . . . . . . . . . . . .
.
1
. . . . . 55
Constant expressions . . . . . . . . . . . . . . .
6.4
. . . . . 57
Declarations . . . . . . . . . . . . . . . . .
6.5
. . . . . 58
6.5.1 Storage-class specifiers . . . . . . . . . . .
. . . . . 58
6.5.2 Type specifiers . . . . . . . . . . . . . .
. . 64
. . . . . . . . . .
6.5.3 Type qualifiers . . . . .
. . . . . . . 65
. . . l . . .
6.5.4 Declarators . . . . . .
. . . . . . 69
. . . . . . . . .
6.5.5 Type names . . . . . .
. . . . . 70
. . . . . . . . . .
6.5.6 Type definitions . . . .
. . . 71
. . . . . . . . . .
6.5.7 Initialization . . . . . .
. . . . 75
. . . . . . . . . . .
6.6 Statements . . . . . . . . .
. . . . 75
. . . . . . . . . . .
6.6.1 Labeled statements . . . .
.... . . 75
. . . . . . . . .
6.6.2 Compound statement, or block
. 76
. . . . . . . . . . . .
6.6.3 Expression and null statements
77
. . . . . . . . . . . . .
6.6.4 Selection statements . . .
78
. . . . . . . . . . . .
6.6.5 Iteration statements . . .
79
. . . . . . . . . . . .
6.6.6 Jump statements . . . .
81
. . . . . . . . . . . . .
6.7 External definitions . . . . . .
81
. . . . . . . . . . . . .
6.7.1 Function definitions
83
. . . . . . . . . . . . . . .
6.7.2 External object definitions l .
85
. . . . . . . . . . . . . . .
6.8 Preprocessing directives
86
. . . . . . . . . . . .
6.8.1 Conditional inclusion . . .
I*
87
. . . . . . . . . . . .
6.8.2 Source file inclusion . . .
89
. . . . . . . . . . . .
6.8.3 Macro replacement . . . .
93
. . . . . . . . . . . .
6.8.4 Line control . . . . . .
93
. . . . . . . . . . . . .
6.8.5 Error directive . . . . .
93
. . . . . . . . . . . .
6.8.6 Pragma directive . . . .
94
. . . . . . . . . . . . .
6.8.7 Null directive
94
. . . . . . . . . . . . . .
6.8.8 Predefined macro ’names’ . .
95
. . . . . . . . . . . .
6.9 Future language directions . . . .
95
. . . . . . . . . . .
6.9.1 External names . . . . .
95
. . . . . . . . . . .
6.9.2 Character escape sequences .
95
. . . . . . . . . . . .
6.9.3 Storage-class specifiers . .
95
. . . . . . . . . . . .
6.9.4 Function declarators . . .
95
. . . . . . . . . . . . . .
6.9.5 Function definitions . . .
95
. . . . . . . . . . . .
6.9.6 Array parameters . . . .
96
. . . . . . . . . . . . . .
7 Library . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . 96
7.1 Introduction
. . . . . . . . . . . 96
7.1.1 Definitibns ’of ‘terms ’ . . . .
. . . . . . . . . . . . . . 96
7.1.2 Standard headers . . . . .
. . . . . . . . . . . . 97
7.1.3 Reserved identifiers . . . .
. . . . . . . . . . . . . . 97
7.1.4 Errors . . . .
..... .' ...... 98
7.1.5 Limits and
............. 98
7.1.6 Common definitions
99
7.1.7 Use of library functions .
101
7.2 Diagnostics .
101
7.2.1 Program diagnostics .
102
h> .
7.3 Character handling 102
................
7.3.1 Character testing functions
104
..............
7.3.2 Character case mapping functions
106
..................
7.4 Localization
107
....................
7.4.1 Locale control
108
............
7.4.2 Numeric formatting convention inquiry
. . .
111

---------------------- Page: 3 ----------------------
ISO/IEC 9899: 1990 (E)
111
7.5 Mathematics .
111
...............
7.5.1 Treatment of error conditions
111
.................
7.5.2 Trigonometric functions
113
7.5.3 Hyperbolic functions .
114
.............
7.5.4 Exponential and logarithmic functions
. . 115
.....
7.5.5 Power functions
116
.......
7.5.6 Nearest integer, absoke value, and rem ’ainder ’fun ’ctions’
118
.................
7.6 Nonlocaljumps
118
.................
7.6.1 Save calling environment
119
................
7.6.2 Restore calling environment
120
.................
7.7 Signal handling
120
.................
7.7.1 Specify signal handling
121
.....................
7.7.2 Send signal
122
h> .
7.8 Variable arguments 122
.............
7.8.1 Variable argument list access macros
124
...................
7.9 Input/output
124
.....................
7.9.1 Introduction
125
......................
7.9.2 Streams
126
.......................
7.9.3 Files
127
...................
7.9.4 Operations on files
128
..................
7.9.5 File access functions
131
..............
7.9.6 Formatted input/output functions
141
...............
7.9.7 Character input/output functions
144
................
7.9.8 Direct input/output functions
145
.................
7.9.9 File positioning functions
147
.................
7.9.10 Error-handling functions
149
.................
7.10 General utilities <&dlib.h>
149
................
7.10.1 String conversion functions
153
..........
7.10.2 Pseudo-random sequence generation functions
154
...............
7.10.3 Memory management functions
155
.............
7.10.4 Communication with the environment
157
...............
7.10.5 Searching and sorting utilities
158
................
7.10.6 Integer arithmetic functions
159
...............
7.10.7 Multibyte character functions
161
................
7.10.8 Multibyte string functions
162
.................
7.11 String handling
162
................
7.11.1 String function conventions
162
...................
7.11.2 Copying functions
163
.................
7.11.3 Concatenation functions
164
..................
7.11.4 Comparison functions
165
. . .
. . . . .
7.11.5 Search functions
168
. .
7.11.6 Miscellaneous functions’
170
....................
7.12 Dateandtime
170
..................
7.12.1 Components of time
170
................
7.12.2 Time manipulation functions
172
................
7.12.3 Time conversion functions
176
...................
7.13 Future library directions
176
..................
7.13.1 Errors
176
..............
. h>
7.13.2 Character handling 176
................
7.13.3 Localization
176
.................
7.13.4 Mathematics
176
...............
7.13.5 Signal handling
176
...............
7.13.6 Input/output
176
...............
7.13.7 General utilities 176
...............
7.13.8 String handling
iv

---------------------- Page: 4 ----------------------
ISO/IEC 9899: 1990 (E)
Annexes
177
. . . . . .
............. . . . . .
A Bibliography
178
. . . . .
......... . e . .
B Language syntax summary
178
. . . .
.......... . . . .
B.1 Lexical grammar
. . . . . 182
....... . . . .
B.2 Phrase structure grammar
. . . . . 187
....... . . .
B.3 Preprocessing directives
. . . . . . . 189
............ . . .
C Sequence points
. . . . . 190
........... . .
D Library summary
. . . . 190
. . . . . . .
D.1 Errors . . . . .
. . . 190
. . . . . . . .
D.2 Common definitions
. . . . 190
. . . . . . .
D.3 Diagnostics . .
. . . . . 190
. . . . . . . .
D.4 Character handling
. . . 190
. . . . . . . .
D.5 Localization . .
191
. . . . . .
. . . . . .
D.6 Mathematics . . .
. . . . . . 191
. . . . . . . .
D.7 Nonlocal jumps
. . . . . . 191
. . . . . . .
D.8 Signal handling
. . . . . . . 192
. . . . . .
D.9 Variable arguments
192
. . . . . .
. . . . .
D.10 Input/output . . .
. . . . . . . 194
. . . . . .
D.11 General utilities
. . . . . . . 195
. . . . . .
D.12 String handling
. . . . . . . . 195
. . . . .
D.13 Date and time . . .
. . . . . . . . . . 196
E Implementation limits . . . . . . . . . l
. . . . . . . . 198
.
F Common warnings . . . . . . . . . . .
. . . . . . . 199
............ . .
G Portability issues
199
. . . . .
........ .
G.l Unspecified behavior
200
. . . . . . .
......... .
G.2 Undefined behavior
204
. . . .
..... . .
G.3 Implementation-defined behavior
. 207
. . . . . . .
....... .
G.4 Locale-specific behavior
208
. . . . .
......... . .
G.5 Common extensions
210
. . . . . .
Index . . . . . . . . . . . . . . . . -

---------------------- Page: 5 ----------------------
ISO/IEC 9899: 1990 (E)
Foreword
IS0 (the International Organization for Standardization) and IEC (the International
Electrotechnical Commission) form the specialized system for worldwide standardiz-
ation. National bodies that are members of IS0 or IEC participate in the development
of International Standards through technical committees established by the respective
organization to deal with particular fields of technical activity. IS0 and IEC technical
committees collaborate in fields of mutual interest. Other international organizations,
governmental and non-governmental, in liaison with IS0 and IEC, also take part in the
work.
In the field of information technology, IS0 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 ?70 of the national bodies casting
a vote.
International Standard ISO/IEC 9899 was prepared by Joint Technical Committee
ISO/IEC JTC 1, Information technology.
Annexes A, B, C, D, E, F and G are for information only.
vi

---------------------- Page: 6 ----------------------
ISO/IEC 9899: 1990 (E)
Introduction
With the introduction of new devices and extended character sets, new features may be added to
this International Standard. Subclauses in the language and library clauses warn implementors and
programmers of usages which, though valid in themselves, may conflict with future additions.
Certain features are obsolescent, which means that they may be considered for withdrawal in future
revisions of this International Standard. They are retained because of their widespread use, but their
use in new implementations (for implementation features) or new programs (for language [6.9] or
library features [7.13]) is discouraged.
This International Standard is divided into four major subdivisions:
- the introduction and preliminary elements;
- the characteristics of environments that translate and execute C programs;
- the language syntax, constraints, and semantics;
- the library facilities.
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. A set of annexes
summarizes information contained in this International Standard. The introduction, the examples, the
footnotes, the references, and the annexes are not part of this International Standard.
The language clause (clause 7) is derived from ‘ ‘The C Reference Manual” (see annex A).
The library clause (clause 8) is based on the 1984 lusr-/group Standard (see annex A).
vii

---------------------- Page: 7 ----------------------
This page intentionally left blank

---------------------- Page: 8 ----------------------
INTERNATIONAL STANDARD
ISO/IEC 9899 : 1990 (E)
Programming languages - C
1 Scope
This International Standard specifies the form and establishes the interpretation of programs
written in the C programming language.’ It specifies
- the representation of C programs;
- the syntax and constraints of the C language;
- the semantic rules for interpreting C programs;
- the representation of input data to be processed by C programs;
- the representation of output data produced by C programs;
- the restrictions and limits imposed by a conforming implementation of C.
This International Standard does not specify
- the mechanism by which C programs are transformed for use by a data-processing system;
- the mechanism by which C programs are invoked for use by a data-processing system;
- the mechanism by which input data are transformed for use by a C program;
- the mechanism by which output data are transformed after being produced by a C program;
- the size or complexity of a program and its data that will exceed the capacity of any specific
data-processing system or the capacity of a particular processor;
- all minimal requirements of a data-processing system that is capable of supporting a
conforming implementation.
2 Normative references
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 IS0 maintain registers of currently valid
International Standards.
IS0 646: 1983, Information processing - IS0 7-bit coded character set for information
interchange .
IS0 4217: 1987, Codes for the representation of currencies and funds.
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. It is accompanied by
a Rationale document that explains many of the decisions of the Technical Committee that produced it.
General

---------------------- Page: 9 ----------------------
ISO/IEC 9899: 1990 (E)
3 Definitions and conventions
interpreted as a requirement on an
In this International Standard, “shall” is to be
is to be interpreted as a prohibition.
implementation or on a program; conversely, “shall not”
For the purposes of this International Standard, the following definitions apply. Other terms
Terms explicitly defined in this
are defined at their first appearance, indicated by italic type.
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
IS0 2382.
3.1 alignment: 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: 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: 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.
3.4 byte: 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: 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.
language
3.6 constraints: Syntactic and semantic restrictions by which the exposition of
elements is to be interpreted.
3.7 diagnostic message: A message belonging to an implementation-defined subset of the
implementation’ s message output.
3.8 forward references: References to later subclauses of this International Standard that
contain additional information relevant to this subclause.
3.9 implementation: 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.10 implementation-defined behavior: Behavior, for a correct program construct and correct
data, that depends on the characteristics of the implementation and that each implementation shall
document.
3.11 implementation limits: Restrictions imposed upon programs by the implementation.
3.12 locale-specific behavior: Behavior that depends on local conventions of nationality,
culture, and language that each implementation shall document.
3.13 multibyte character: 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.14 object: 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.
2 General

---------------------- Page: 10 ----------------------
ISO/IEC 9899: 1990 (E)
3.15 parameter: 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.16 undefined behavior: 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).
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.17 unspecified behavior: Behavior, for a correct program construct and correct data, for
which this Intema .tional Standard explicitly imposes no requirements.
Examples
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 imple mentation -defined behavior is the propagation of the high-order bit
when a signed i nteger is shifted right.
4. An example of locale-specific behavior is whether the islower function returns true for
characters other than the 26 lowercase English letters.
Forward references: bitwise shift operators (6.3.7), expressions (6.3), function calls (6.3.2.2),
the islower function (7.3.1.6), localization (7.4).
4 Compliance
A strictly conforming program shall use only those features of the language and library
specified in this International Standard. It shall not produce output dependent on any unspecified,
undefined, or implementation-defined behavior, and shall not exceed any minimum
implementation limit.
The two forms of conforming implementation are hosted and freestanding. A conforming
hosted implementation shall accept any strictly conforming program. A conforming fi-eestanding
impzementation 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
, , , and . A c,onforrning implementation
may have extensions (including additional library functions), provided they do not alter the
behavior of any strictly conforming program.”
A conforming program is one that is acceptable to a conforming implementation.”
2 This implies that a conforming implementation reserves no identifiers other than those explicitly reserved
in this International Standard.
3 Strictly conforming programs are intended to be maximally portable among conforming implementations.
Conforming programs may depend upon nonportable features of a conforming implementation.
General

---------------------- Page: 11 ----------------------
ISO/IEC 9899: 1990 (E)
An implementation shall be accompanied document that defines all implementation-
bY a
defined characteristics and all extensions.
Forward references: limits (7.1 S), variable
.h> and arguments
(7.8), common definitions .
(7.1. 6)
General

---------------------- Page: 12 ----------------------
ISO/IEC 9899: 1990 (E)
5 Environment
An implementation translates C source files and executes C programs in two data-processing-
system environments, which will be called the translation environment and the execution
environment in this International Standard. Their characteristics define and constrain the results
of executing conforming C programs constructed according to the syntactic and semantic rules for
conforming implementations.
Forward references: In the environment clause (clause 5), only a few of many possible forward
references have been noted.
5.1 Conceptual models
51.1 Translation environment
5.1.1.1 Program structure
A C program need not all be translated at the same time. The text of the program is kept in
units called source files in this International Standard. A source file together with all the headers
and source files included via the preprocessing directive #include, less any source lines
skipped by any of the conditional inclusion preprocessing directives, 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. l), linkages of identifiers (6.1.2.2), source file
inclusion (6.8.2).
5.1.1.2 Translation phases
The precedence among the syntax rules of translation is specified by the following phases.4
1. Physical source file characters are mapped 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 new-line character and an immediately preceding backslash character is
deleted, splicing physical source lines to form logical source lines. A source file that is not
empty shall end in a new-line character, which shall not be immediately preceded by a
backslash character.
3. The source file is decomposed into preprocessing tokens5 and sequences of white-space
characters (including comments). ,4 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 and macro invocations are expanded. A #include
preprocessing directive causes the named header or source file to be processed from phase
1 through phase 4, recursively.
4 Implementations must behave as if these separate phases occur, even though many are typically folded
together in practice.
5 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.
Environment

---------------------- Page: 13 ----------------------
ISO/IEC 9899: 1990 (E)
and string
5. Each source character set member and escape sequence in character constants
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.
Library components are linked to
8. All-external object and function references are resolved.
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:
lexical elements (6.1) preprocessing directives (6.8), trigraph sequences
(5.2.1.1).
5.1.1.3 Diagnostics
A conforming implementation shall produce at least one diagnostic message (identified in an
implementation-defined manner) for every translation unit that contains a violation of any syntax
rule or constraint. Diagnostic messages need not be produced in other circumstances.6
51.2 Execution environments
Two execution environments are defined: Ji-eestanding 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.
Forward references: initialization (6.5.7).
5.1.2.1 Freestanding environment
In a freestanding environment (in which C program execution may take place without any
benefit of an operating system), the name and type of the function called at program startup are
implementation-defined. There are otherwise no reserved external identifiers. Any library
facilities available to a freestanding program are implementation-d
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.