ISO/IEC 9899:1990/Cor 2:1996
(Corrigendum)Programming languages — C — Technical Corrigendum 2
Programming languages — C — Technical Corrigendum 2
Langages de programmation — C — Rectificatif technique 2
General Information
Relations
Standards Content (Sample)
INTERNATIONAL STANDARD ISO/IEC 9899:1990
TECHNICAL CORRIGENDUM 2
Published 1996-04-01
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION- MEXfiYHAPOjJHAR OPTAHM3AUMR l-l0 CTAHflAPTl43AUMlrl* ORGANISATION INTERNATIONALE DE NORMALISATION
INTERNATIONAL ELECTROTECHNICAL COMMISSION- MEXDYHAPO~~HAR ~~~EKTPOTEXHM~ECKAR KOMMCC~~F~- COMMISSION ELECTR~TECHN~OUE INTERNATIONALE
Programming languages - C
TECHNICAL CORRIGENDUM 2
Langages de programmation - C
RECTIFICATIF TECHNIQUE 2
Technical corrigendum 2 to International Standard lSO/lEC 9899:1990 was prepared by Joint Technical Committee
lSO/lEC JTC 1, Mormation technology.
Page 6
In subclause 5.1.2.1, page 6, delete:
There are otherwise no reserved external identifiers.
Page 7
In subclause 5.1.2.2.3, page 7, add at the end of the fist sentence the footnote:
In accordance with subclause 6.1.2.4, objects with automatic storage duration declared in main will no
longer have storage guaranteed to be reserved in the former case even where they would in the latter.
Page 11
In subclause 5.2.1.2, page 11, change the third bullet item:
wherein each sequence of multibyte characters begins in an initial shifr state and enters other implementa-
tion-defined shift states
to:
wherein each sequence of multibyte characters begins in an initial shifr state and enters other locale-specific
shifr states
Page 22
In subclause 6.1.2.4, page 22, fm t paragraph, change:
There are two storage durations: static and automatic.
to:
There are three storage durations: static, automatic, and allocated. Allocated storage is described in 7.10.3.
ICS 35.060 Ref. No. ISO/IEC 9899:1990/Cor.2: 1996( E)
Descriptors: data processing, computer software, artificial languages, programming languages, C (programming language).
0 ISO/IEC 1996
Printed in Switzerland
---------------------- Page: 1 ----------------------
0 ISOIIEC
ISO/IEC 9899: 1990Kor.2: 1996(E)
Page 25
In subclause 6.1.2.6, page 25, f”lrst paragraph, change:
Moreover, two structure, union, or enumerated types declared in separate translation units are compatible
if they have the same number of members, the same member names, and compatible member types; for two
structures, the members shall be in the same order; for two structures or unions, the bit-fields shall have the
same widths; for two enumerated types, the members shall have the same values.
to:
Moreover, two structure, union, or enumerated types declared in separate translation units are compatible
if at least one is an incomplete type or if they have the same number of members, the same member names,
and compatible member types; for two complete structure types, the members shall be in the same order;
for two complete structure or union types, the bit-fields shall have the same widths; for two enumerated
types, the members shall have the same values.
Page 31
In subclause 6.1.4, page 31, change the last paragraph of Semantics (&fore the Example) from:
Identical string literals of either form need not be distinct. If the program attempts to modify a string literal
of either form, the behavior is undefined.
to:
These arrays need not be distinct provided their elements have the appropriate values. If the program
- -
attempts to modify such an array, the behavior is undefined.
Page 36
In subclause 6.2.2.1, page 36, change the parenthetic remark in the jinal sentence of the fwstparagraph:
(including, recursively, any member of all contained structures or unions)
to:
(including, recursively, any member or element of all contained aggregates or unions)
Page 41
In subclause 6.3.2.2, page 41, second paragraph, change:
If the expression that denotes the calkd function has a type that includes a prototype, the
arguments are implicitly converted, as if by assignment, to the types of the corresponding
parameters.
If the expression that denotes the called function has a type that includes a prototype, the
arguments are implicitly converted, as if by assignment, to the types of the corresponding
parameters, taking the type of each parameter to be the unqualified version of its declared type.
Page 45
In subclause 6.3.4, page 45, change the paragraph under Constraints:
Unless the type name specifies void type, the type name shall specify qualified or unqualified scalar type
and the operand shall have scalar type.
to:
Unless the type name specifies a void type, the type name shall specify qualified or unqualified scalar type
and the operand shall have scalar type.
Page 61
In sub&use 6.5.2.2, page 61, second paragraph of Semantics, change:
Each enumerated type shall be compatible with an integer type; the choice of type is implementation-de-
fined.
to:
Each enumerated type shall be compatible with an integer type. The ch
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.