ISO/IEC 9899:1990

Programming languages - C

Langages de programmation — C

General Information

• Status: Withdrawn
• Publication Date: 19-Dec-1990
• Withdrawal Date: 19-Dec-1990
• 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: 16-Dec-1999
• Completion Date: 30-Oct-2025

Relations

• Amended By: ISO/IEC 9899:1990/Amd 1:1995 - Programming languages - C - Amendment 1: C Integrity
• Effective Date: 06-Jun-2022
• Corrected By: ISO/IEC 9899:1990/Cor 2:1996 - Programming languages - C - Technical Corrigendum 2
• Effective Date: 06-Jun-2022
• Corrected By: ISO/IEC 9899:1990/Cor 1:1994 - Programming languages - C - Technical Corrigendum 1
• Effective Date: 06-Jun-2022
• Revised: ISO/IEC 9899:1999 - Programming languages - C
• Effective Date: 15-Apr-2008
• Parent: ISO/IEC 9899:1990/Cor 1:1994 - Programming languages - C - Technical Corrigendum 1
• Effective Date: 15-Apr-2008
• Parent: ISO/IEC 9899:1990/Amd 1:1995 - Programming languages - C - Amendment 1: C Integrity
• Effective Date: 15-Apr-2008
• Parent: ISO/IEC 9899:1990/Cor 2:1996 - Programming languages - C - Technical Corrigendum 2
• Effective Date: 15-Apr-2008

Standards Content (Sample)

INTERNATIONAL
ISOIIEC
STANDARD
First edition
1990-12-15
Programming languages - C
Langages de programmation - C
w
E
-
-
=
= E
=
=
=
=
= =
= z
z
= =
=
=.
s
= =
-
C Reference number
E Z
E-
-
ISOAEC 9899 : 1990 (El
ISO/IEC 9899: 1990 (E)
Contents
1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Normative references . . . . . . . . . . . . . . . . . . . . . .
3 Definitions and conventions . . . . . . . . . . . . . . . . . . . .
4 Compliance . . . . . . . . . . . . . . . . . . . . . . . . .
.........................
5 Environment
.....................
5.1 Conceptual models
.................
51.1 Translation environment
.................
51.2 Execution environments
..................
5.2 Environmental considerations
....................
5.2.1 Character sets
................
5.2.2 Character display semantics
..................
5.2.3 Signals and interrupts
..................
5.2.4 Environmental limits
..........................
6 Language
......................
6.1 Lexical elements
.....................
6.1.1 Keywords
.....................
6.1.2 Identifiers
....................
6.1.3 Constants
.....................
6.1.4 String literals
6.1.5 Operators .
6.1.6 Punctuators .
6.1.7 Header names .
6.1.8 Preprocessing numbers .
.....................
6.1.9 Comments
.......................
6.2 Conversions
..................
6.2.1 Arithmetic operands
....................
6.2.2 Other operands
.......................
6.3 Expressions
..................
6.3.1 Primary expressions
...................
6.3.2 Postfix operators
....................
Unary operators
6.3.3
Cast operators .
6.3.4
.................
6.3.5 Multiplicative operators
...................
6.3.6 Additive operators
..................
6.3.7 Bitwise shift operators
..................
6.3.8 Relational operators
...................
Equality operators
6.3.9
..................
Bitwise AND operator
6.3.10
...............
6.3.11 Bitwise exclusive OR operator
...............
6.3.12 Bitwise inclusive OR operator
..................
6.3.13 Logical AND operator
..................
6.3.14 Logical OR operator
..................
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
ISO/IEC 9899: 1990 (E)
. . . . . . . . 53
6.3.16 Assignment operators . . . . . . . . . .
. . . . . 54
6.3.17 Comma operator . . . . . . . . . . . . . .
.
. . . . . 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
. . . . . . . . . . . . .
6.6.4 Selection statements . . .
. . . . . . . . . . . .
6.6.5 Iteration statements . . .
. . . . . . . . . . . .
6.6.6 Jump statements . . . .
. . . . . . . . . . . . .
6.7 External definitions . . . . . .
. . . . . . . . . . . . .
6.7.1 Function definitions
. . . . . . . . . . . . . . .
6.7.2 External object definitions l .
. . . . . . . . . . . . . . .
6.8 Preprocessing directives
. . . . . . . . . . . .
6.8.1 Conditional inclusion . . .
I*
. . . . . . . . . . . .
6.8.2 Source file inclusion . . .
. . . . . . . . . . . .
6.8.3 Macro replacement . . . .
. . . . . . . . . . . .
6.8.4 Line control . . . . . .
. . . . . . . . . . . . .
6.8.5 Error directive . . . . .
. . . . . . . . . . . .
6.8.6 Pragma directive . . . .
. . . . . . . . . . . . .
6.8.7 Null directive
. . . . . . . . . . . . . .
6.8.8 Predefined macro ’names’ . .
. . . . . . . . . . . .
6.9 Future language directions . . . .
. . . . . . . . . . .
6.9.1 External names . . . . .
. . . . . . . . . . .
6.9.2 Character escape sequences .
. . . . . . . . . . . .
6.9.3 Storage-class specifiers . .
. . . . . . . . . . . .
6.9.4 Function declarators . . .
. . . . . . . . . . . . . .
6.9.5 Function definitions . . .
. . . . . . . . . . . .
6.9.6 Array parameters . . . .
. . . . . . . . . . . . . .
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
7.1.7 Use of library functions .
7.2 Diagnostics .
7.2.1 Program diagnostics .
h> .
7.3 Character handling ................
7.3.1 Character testing functions
..............
7.3.2 Character case mapping functions
..................
7.4 Localization
....................
7.4.1 Locale control
............
7.4.2 Numeric formatting convention inquiry
. . .
ISO/IEC 9899: 1990 (E)
7.5 Mathematics .
...............
7.5.1 Treatment of error conditions
.................
7.5.2 Trigonometric functions
7.5.3 Hyperbolic functions .
.............
7.5.4 Exponential and logarithmic functions
. . 115
.....
7.5.5 Power functions
.......
7.5.6 Nearest integer, absoke value, and rem ’ainder ’fun ’ctions’
.................
7.6 Nonlocaljumps
.................
7.6.1 Save calling environment
................
7.6.2 Restore calling environment
.................
7.7 Signal handling
.................
7.7.1 Specify signal handling
.....................
7.7.2 Send signal
h> .
7.8 Variable arguments .............
7.8.1 Variable argument list access macros
...................
7.9 Input/output
.....................
7.9.1 Introduction
......................
7.9.2 Streams
.......................
7.9.3 Files
...................
7.9.4 Operations on files
..................
7.9.5 File access functions
..............
7.9.6 Formatted input/output functions
...............
7.9.7 Character input/output functions
................
7.9.8 Direct input/output functions
.................
7.9.9 File positioning functions
.................
7.9.10 Error-handling functions
.................
7.10 General utilities <&dlib.h>
................
7.10.1 String conversion functions
..........
7.10.2 Pseudo-random sequence generation functions
...............
7.10.3 Memory management functions
.............
7.10.4 Communication with the environment
...............
7.10.5 Searching and sorting utilities
................
7.10.6 Integer arithmetic functions
...............
7.10.7 Multibyte character functions
................
7.10.8 Multibyte string functions
.................
7.11 String handling
................
7.11.1 String function conventions
...................
7.11.2 Copying functions
.................
7.11.3 Concatenation functions
..................
7.11.4 Comparison functions
. . .
. . . . .
7.11.5 Search functions
. .
7.11.6 Miscellaneous functions’
....................
7.12 Dateandtime
..................
7.12.1 Components of time
................
7.12.2 Time manipulation functions
................
7.12.3 Time conversion functions
...................
7.13 Future library directions
..................
7.13.1 Errors
..............
. h>
7.13.2 Character handling ................
7.13.3 Localization
.................
7.13.4 Mathematics
...............
7.13.5 Signal handling
...............
7.13.6 Input/output
...............
7.13.7 General utilities ...............
7.13.8 String handling
iv
ISO/IEC 9899: 1990 (E)
Annexes
. . . . . .
............. . . . . .
A Bibliography
. . . . .
......... . e . .
B Language syntax summary
. . . .
.......... . . . .
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 . .
. . . . . .
. . . . . .
D.6 Mathematics . . .
. . . . . . 191
. . . . . . . .
D.7 Nonlocal jumps
. . . . . . 191
. . . . . . .
D.8 Signal handling
. . . . . . . 192
. . . . . .
D.9 Variable arguments
. . . . . .
. . . . .
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
. . . . .
........ .
G.l Unspecified behavior
. . . . . . .
......... .
G.2 Undefined behavior
. . . .
..... . .
G.3 Implementation-defined behavior
. 207
. . . . . . .
....... .
G.4 Locale-specific behavior
. . . . .
......... . .
G.5 Common extensions
. . . . . .
Index . . . . . . . . . . . . . . . . -

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
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
This page intentionally left blank

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
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
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
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
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
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-defined.
The effect of program termination in a freestanding environment is implementation-defined.
5.1.2.2 Hosted environment
A hosted environment need not be provided, but shall conform to the following specificati ons
if present.
5.1.2.2.1 Program startup
The function called at program startup is named main. The implementation declares no
prototype for this function. It can 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):
6 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.
Environment
ISO/IEC 9899: 1990 (E)
int main(int argc, char *argv[]) { /*.*/ )
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.
the array members argv [ 0] through
- If the value of argc is greater than zero,
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 [ l] through argv [ argc- 1 ] represent the program parameters.
- The parameters argc and argv and the strings pointed to by the argv array shall be
modifiable by the program, and retain their last-stored values between program startup and
program termination.
5.1.2.2.2 Program execution
In a hosted environment, a program may functions, macros, type definitions, and
use all the
objects described in the library clause (clause
7).
5.1.2.2.3 Program termination
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. If the main function executes a
return that specifies no value, the termination status returned to the host environment is
undefined.
Forward references: definition of terms (7.1. l), the exit function (7.10.4.3).
5.1.2.3 Program execution
The seman tic descriptions in this Intern ational Stand ard d .escri be the behavior of an abstract
achine in wh ich issues of optimizati .on are irrelev ant.
Accessing a volatile object, modifying an object, modifying a file, or calling a function that
does any of those operations are all side efjCects, 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.
In the abstract machine, all expressions are evaluated as specified by the semantics. An actual
implementation need not evaluate part of an expression if it can deduce that its value is not used
and that no needed side effects are produced (including any caused by calling a function or
accessing a volatile object).
When the processing of the abstract machine is interrupted by receipt of a signal, only the
values of objects as of the previous sequence point may be relied on. Objects that may be
modified between the previous sequence point and the next sequence point need not have
received their correct values yet.
An instance of each object with automatic storage duration is associated with each entry into
its block. Such 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).
Environment
ISO/IEC 9899: 1990 (E)
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.9.3.
The intent of these requirements is that unbuffered or line-buffered output appear as soon as
possible, to ensure that prompting messages actually appear prior to a program waiting for
input.
What constitutes an interactive device is implementation-defined.
More stringent correspondences between abstract and actual semantics may be defined by
each implementation.
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 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 cl, c2;
/*.*/
cl = cl + c2;
the “integral 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 creating an overflow exception, the actual
execution need only produce the same result, possibly omitting the promotions.
3. Similarly, in the fragment
float fl, f2;
double d;
/*.*/
fl = 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). Alternatively, an operation involving only ints or floats may be executed
using double-precision operations if neither range nor precision is lost thereby.
4. To illustrate the grouping behavior of expressions, in the following fragment
Environment
ISO/IEC 9899: 1990 (E)
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 exception 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 an exception while the original expression would not; nor can the expression be
rewritten either as
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 overflows do not produce an exception and in which the
results of overflows are reversible, the above expression statement can be rewritten by the
implementation in any of the above ways because the same result will occur.
5. The grouping of an expression does not completely determine its evaluation. In the
following fragment
#include
int sum;
char *p;
. . .
/* */
sum = sum * 10 - '0' + (*p++ = getchar(
the express ion statement is grouped as if it were written as
sum = (((sum * 10) -
‘0 ’) + U*tp++H = (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.9.3),
sequence points (6.3, 6.6), the signal function (7.7), type qualifiers (6.5.3).
Environment
ISO/IEC 9899: 1990 (E)
5.2 Environmental considerations
5.2.1 Character sets
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.
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 literal.
Both the basic source and basic execution character sets shall have at least the following
members: the 26 uppercase letters of the English alphabet
ABCDEFGHI J K L M
NOPQRS TUVWXYZ
the 26 lowercase letters of the English alphabet
abcdefghij klm
n 0 pqrstuvwxyz
the 10 decimal digits
the following 29 graphic characters
II # % &’ () * +, - l / :
!
< = > ?
; [ \ 1 h 1 I 1 -
-
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 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.
Forward references: character constants (6.1.3.4), preprocessing directives (6.8), string literals
(6.1.4), comments (6.1.9).
5.2.1.1 Trigraph sequences
All occurrences in a source file of the following sequences of three characters (called trigraph
sequences7) are replaced with the corresponding single character.
7 The trigraph sequences enable the input of characters that are not defined in the Invariant Code Set as
described in IS0 646: 1983, which is a subset of the seven-bit ASCII code set.
Environment
ISO/IEC 9899: 1990 (E)
??=
#
?? (
??/ \
??)
A
33’
. .
??<
i
??!
I
??>
N
??-
No other trigraph sequences exist. Each ? that does not begin one of the trigraphs listed above
is not changed.
The following source line
printf("Eh???/n");
becomes (after replacement of the trigraph sequence ? ? /)
printf("Eh?\n");
5.2.1.2 Multibyte characters
The source character set may contain multibyte characters, used to represent members of the
extended character set. The execution character set may also contain multibyte characters, which
need not have the same encoding as for the source character set. For both character sets, the
following shall hold:
- The 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 implementation-defined
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.
- A byte with all bits zero shall not occur in the second or subsequent bytes of a multi byte
character.
For the source character set, the following shall hold:
character constant, or header name shall begin and end in the initial
- A comment, string literal,
shift state.
character constant, or header name
- A comment, string literal, shall consist of a sequence of
valid multibyte characters.
Environment
ISO/IEC 9899: 1990 (E)
5.2.2 Character display semantics
The active position is that location on a display device where the next character output by the
f put c 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.
Alphabetic escape sequences representing nongraphic characters in the execution character set
intended to produc
...