Standard specifies the form and establishes the interpretation of programs
written in the C programming language./1/
representation of C programs;
syntax and constraints of the C language;
semantic rules for interpreting C programs;
representation of input data to be processed by C programs;
representation of output data produced by C programs;
restrictions and limits imposed by a conforming implementation of C.
Standard does not specify:
mechanism by which C programs are transformed for use by a data-processing
mechanism by which C programs are invoked for use by a data-processing system;
mechanism by which input data are transformed for use by a C program;
mechanism by which output data are transformed after being produced by a C
* 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;
minimal requirements of a data-processing system that is capable of supporting a
1. ``The C
Reference Manual'' by Dennis M. Ritchie, a version of which was published in The
C Programming Language by Brian W. Kernighan and Dennis M. Ritchie,
Prentice-Hall, Inc., (1978). Copyright
owned by AT&T.
2. 1984 /usr/group
Standard by the /usr/group Standards Committee, Santa Clara, California, USA (November,
American National Dictionary for Information Processing Systems
,Information Processing Systems Technical Report ANSI X3/TR-1-82 (1982).
646-1983 Invariant Code Set.
Standard for Binary Floating-Point Arithmetic (ANSI/IEEE Std 754-1985).
4217 Codes for the Representation of Currency and Funds.
document is divided into four major sections:
characteristics of environments that translate and execute C programs;
language syntax, constraints, and semantics;
are provided to illustrate possible forms of the constructions
described. Footnotes are
provided to emphasize consequences of the rules described in the section or
elsewhere in the Standard. References
are used to refer to other related sections.
A set of appendices summarizes information contained in the Standard.
The abstract, the foreword, the examples, the footnotes, the references,
and the appendices are not part of the Standard.
language section ($3) is derived from ``The C Reference Manual'' by Dennis M.
Ritchie, a version of which was published as Appendix A of The C Programming
Language by Brian W. Kernighan and Dennis M. Ritchie, Prentice-Hall, Inc., 1978;
copyright owned by AT&T.
library section ($4) is based on the 1984 /usr/group Standard by the /usr/group
Standards Committee, Santa Clara, California, USA (November 14, 1984).
this 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.
following terms are used in this document:
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.
* 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.
* Byte ---
the unit of data storage in the execution environment 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.
--- 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
Character --- a single byte representing a member of the basic character set of
either the source or the execution environment.
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.
Alignment --- a requirement that objects of a particular type be located on
storage boundaries with addresses that are particular multiples of a byte
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.''
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.''
Unspecified behavior --- behavior, for a correct program construct and correct
data, for which the Standard imposes no requirements.
Undefined behavior --- behavior, upon use of a nonportable or erroneous program
construct, of erroneous data, or of indeterminately-valued objects, for which
the 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 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.''
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.
Locale-specific behavior --- behavior that depends on local conventions of
nationality, culture, and language that each implementation shall document.
Diagnostic message --- a message belonging to an implementation-defined subset
of the implementation's message output.
Constraints --- syntactic and semantic restrictions by which the exposition of
language elements is to be interpreted.
Implementation limits --- restrictions imposed upon programs by the
Forward references --- references to later sections of the Standard that contain
additional information relevant to this section.
Other terms are defined at their first appearance, indicated by italic
type. Terms explicitly defined in
this Standard are not to be presumed to refer implicitly to similar terms
defined elsewhere. Terms not defined in this Standard are to be interpreted
according to the American National Dictionary for Information Processing Systems
,Information Processing Systems Technical Report
ANSI X3/TR-1-82 (1982).
references: localization ($4.4).
An example of unspecified behavior is the order in which the arguments to
a function are evaluated.
An example of undefined behavior is the behavior on integer overflow.
An example of implementation-defined behavior is the propagation of the
high-order bit when a signed integer is shifted right.
An example of locale-specific behavior is whether the islower function
returns true for characters other than the 26 lower-case English letters.
references: bitwise shift operators ($3.3.7), expressions
($3.3), function calls ($184.108.40.206), the islower function
A strictly conforming program shall use only those features of the
language and library specified in this Standard.
It shall not produce output dependent on any unspecified, undefined, or
implementation-defined behavior, and shall not exceed any minimum implementation
The two forms of conforming implementation are hosted and freestanding.
A conforming hosted implementation shall accept any strictly conforming
program. A conforming freestanding
implementation shall accept any strictly conforming program in which the use of
the features specified in the library section ($4) is confined to the contents
of the standard headers <float.h> , <limits.h> , <stdarg.h> ,
and <stddef.h> . A conforming
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
An implementation shall be accompanied by a document that defines all
implementation-defined characteristics and all extensions.
references: limits <float.h> and <limits.h> ($4.1.4), variable
arguments <stdarg.h> ($4.8), common definitions <stddef.h>
With the introduction of new devices and extended character sets, new
features may be added to the Standard. Subsections
in the language and library sections 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 the Standard.
They are retained in the Standard because of their widespread use, but
their use in new implementations (for implementation features) or new programs (for
language or library features) is discouraged.
references: future language directions ($3.9.9), future library directions
Symbols in the right margin mark substantive differences between this
draft and its predecessor (ANSI X3J11/88-001, January 11, 1988).
A plus sign indicates an addition, a minus sign a deletion, and a
vertical bar a replacement.
This section and the difference marks themselves will not appear in the
[Contents] [Previous] [Next] [Home]
webmaster Massimo F. ARENA