JTC1/SC22/WG14
N746
WG14 N746
J11/97-109
ISO/IEC JTC 1/SC22
Programming languages, their environments and system software interfaces
Secretariat: U.S.A. (ANSI)
ISO/IEC JTC 1/SC22
N2541
August 1997
TITLE:
Summary of Voting on CD Registration for CD 9899 - Information technology
- Programming languages - Programming Language C (Revision of ISO/IEC
9899:1990)
SOURCE:
Secretariat, ISO/IEC JTC 1/SC22
WORK ITEM:
JTC 1.22.20.01
STATUS:
CD 9899 has been registered.
CROSS REFERENCE:
SC22 N2444
DOCUMENT TYPE:
Summary of Voting
ACTION:
To SC22 Member Bodies for information.
To WG14 for preparation of a Disposition of Comments Report and a
recommendation on the further processing of the CD.
Address reply to:
ISO/IEC JTC 1/SC22 Secretariat
William C. Rinehuls
8457 Rushing Creek Court
Springfield, VA 22153 USA
Tel: +1 (703) 912-9680
Fax: +1 (703) 912-2973
email: [email protected]
____________end of title page; beginning of overall summary ____________
SUMMARY OF VOTING ON
Letter Ballot Reference No: SC22 N2444
Circulated by: JTC 1/SC22
Circulation Date: 04-09-1997
Closing Date: 07-25-1997
SUBJECT: CD Registration Ballot for CD 9899: Information technology -
Programming languages - Programming Language C (Revision of
ISO/IEC 9899:1990)
The following responses have been received on the subject of approval:
"P" Members supporting approval
without comment 13
"P" Members supporting approval
with comment 1
"P" Members not supporting approval 1
"P" Members abstaining 3
"P" Members not voting 6
Secretariat Action:
CD 9899 has been registered.
The comment accompanying the abstention vote from Austria was: "Lack of
expert resources." The comment accompanying the abstention vote from
France was: "Due to lack of resources". The comment accompanying the
abstention vote from Germany was: "There is no national WG14 rapporteur."
The comments accompanying the affirmative vote from Japan and the comments
accompanying the negative vote from Denmark are attached.
WG14 is requested to prepare a Disposition of Comments Report and make a
recommendation on the further processing of the CD.
_________ end of overall summary; beginning of detailed summary _____
ISO/IEC JTC1/SC22 LETTER BALLOT SUMMARY
PROJECT NO: JTC 1.22.20.01
SUBJECT: CD Registration Ballot for CD 9899: Information technology
- Programming languages - Programming Language C (Revision
of ISO/IEC 9899:1990)
Reference Document No: N2444 Ballot Document No: N2444
Circulation Date: 04-09-1997 Closing Date: 07-25-1997
Circulated To: SC22 P,L Circulated By: Secretariat
SUMMARY OF VOTING AND COMMENTS RECEIVED
Approve Disapprove Abstain Comments Not Voting
'P' Members
Australia (X) ( ) ( ) ( ) ( )
Austria ( ) ( ) (X) (X) ( )
Belgium (X) ( ) ( ) ( ) ( )
Brazil ( ) ( ) ( ) ( ) (X)
Canada (X) ( ) ( ) ( ) ( )
China ( ) ( ) ( ) ( ) (X)
Czech Republic ( ) ( ) ( ) ( ) (X)
Denmark ( ) (X) ( ) (X) ( )
Egypt (X) ( ) ( ) ( ) ( )
Finland (X) ( ) ( ) ( ) ( )
France ( ) ( ) (X) (X) ( )
Germany ( ) ( ) (X) (X) ( )
Ireland ( ) ( ) ( ) ( ) (X)
Japan (X) ( ) ( ) (X) ( )
Netherlands (X) ( ) ( ) ( ) ( )
Norway (X) ( ) ( ) ( ) ( )
Romania ( ) ( ) ( ) ( ) (X)
Russian Federation (X) ( ) ( ) ( ) ( )
Slovenia ( ) ( ) ( ) ( ) (X)
Sweden (X) ( ) ( ) ( ) ( )
Switzerland (X) ( ) ( ) ( ) ( )
UK (X) ( ) ( ) ( ) ( )
Ukraine (X) ( ) ( ) ( ) ( )
USA (X) ( ) ( ) ( ) ( )
'O' Members
Argentina ( ) ( ) ( ) ( ) ( )
Bulgaria ( ) ( ) ( ) ( ) ( )
Cuba ( ) ( ) ( ) ( ) ( )
Greece ( ) ( ) ( ) ( ) ( )
Hungary ( ) ( ) ( ) ( ) ( )
Iceland ( ) ( ) ( ) ( ) ( )
India ( ) ( ) ( ) ( ) ( )
Indonesia ( ) ( ) ( ) ( ) ( )
Italy ( ) ( ) ( ) ( ) ( )
Korea Republic ( ) ( ) ( ) ( ) ( )
New Zealand ( ) ( ) ( ) ( ) ( )
Poland ( ) ( ) ( ) ( ) ( )
Portugal ( ) ( ) ( ) ( ) ( )
Singapore ( ) ( ) ( ) ( ) ( )
Thailand ( ) ( ) ( ) ( ) ( )
Turkey ( ) ( ) ( ) ( ) ( )
Yugoslavia ( ) ( ) ( ) ( ) ( )
_____________ end of overall summary; beginning of Danish comments __
Hereby the Danish vote on SC22 N2444 - CD Registration ISO/IEC 9899 C
The Danish vote is "no".
The document does not have a number of required components.
DS is missing:
1. POSIX alignment on internationalization functionality
2. POSIX alignment with strftime()
3. Basic IO functionality
4. Boolean type capabilities
The vote will be changed to "yes" if functionality for the 4 areas
is included in the specification.
It is also our opinion that a number of other facilities that WG14
has wanted to be in the standard, is not included in the document.
___________end of Danish comments; beginning of Japanese comments _____
Japanese Vote for ISO/IEC JTC1/SC22 N 2444
CD Registration Ballot for CD 9899:
Information technology - Programming languages -
Programming Language C (revision of ISO/IEC 9899:1990)
Japan votes "YES" on ISO/IEC JTC1/SC22 N 2444, "CD
Registration Ballot for CD 9899: Information technology -
Programming languages - Programming Language C (revision of
ISO/IEC 9899:1990)" with the following comments:
1. Technical Comments
---------------------
1) Type long long int and lldiv_t should be optional.
Paragraph 1 of subclause 5.2.4.1 (page 19 in draft 9),
paragraph 3 of subclause 6.1.2.5 (page 32 in draft 9),
constraints of subclause 6.5.2 (page 83 in draft 9), and
paragraph 2 of subclause 7.13 (page 258 in draft 9):
Type (unsigned) long long int is introduced into the draft 9
as a mandatory part of the standard C. The maximum and
minimum values for an object of type (unsigned) long long
int are defined in the subclause 5.2.4.2. These values need
to be represented by using 64 bit data type. Implementation
of type (unsigned) long long int, however, is too hard for
the compiler on the currently widely used 16 or 32 bit
architecture machines. The cross compiler on the small
machine must especially face a big difficulty when
implementing type (unsigned) long long int. Therefore,
type (unsigned) long long int should be a part of an
optional specification or a part of the common extension of
the standard C.
A new type lldiv_t defined in subclause 7.13 should be
reconsidered as well as type long long int.
2) Type complex should be optional.
Paragraph 7 of subclause 6.1.2.5 (page 33 in draft 9):
Japan thinks the number of the user of type complex is not
so big. Therefore, type complex should be optional or a
part of the common extension of the standard C.
3) Function atoll() should be dropped.
Subclause 7.13.1.4 (page 260 in draft 9):
A new function atoll() is redundant for the standard C.
(Every ato*() functions can be replaced by strto*().)
The functions which can be directly replaced by other
functions should not be included in the standard C. Not
introducing redundant functions was one of the important
policies of development of the Amendment 1. This policy is
clearly described in the annex B.3 of the Amendment 1. If
the committee had determined to include the function atoll()
by some strong reason, why are NOT atod(), atold() included
in the draft 9? Please drop atoll() from the draft, or please
document a clear rationale which describes the reason why only
atoll() was added.
4) Encoding of the execution character set and the source
character set
Paragraph 1 of subclause 5.2.1.2 (page 16 in draft 9):
The draft says in paragraph 1 of subclause 5.2.1.2:
The execution character set may also contain
multibyte characters, which need not have the same
encoding as for the source character set.
- The presence, meaning, and representation of any
additional members is locale-specific.
This description implies that the program needs to behave
correctly even if the encoding is different between the
execution character set and the source character set.
This requirement is too heavy for the implementer of the
standard C. Therefore, the standard should say explicitly
that the behavior is *unspecified* when the encoding is
different between the execution character set and the source
character set.
5) Illegal example of ## operator
Paragraph 4 (example) of subclause 6.8.3.3 (page 131 in
draft 9):
In the Example of the ## operator(paragraph 4 of
subclause 6.8.3.3 (page 131)), that is,
-----------------------------------------------------
#define hash_hash # ## #
#define mkstr(a) # a
#define in_between(a) mkstr(a)
#define join(c, d) in_between(c hash_hash d)
char p[] = join(x, y); /* equivalent to */
/* char p[] = "x ## y"; */
The expansion produces, at various stages:
join(x, y)
in_between(x hash_hash y)
in_between(x ## y) ---- line (A)
mkstr(x ## y)
"x ## y"
-----------------------------------------------------
an object-like macro "hash_hash" is replaced by "##" at
line (A). Well then, what kind of preprocessing-token is
the "##" at line (A)?
First, we can not find out any preprocessing-token other
than "operator" for ##, therefore, the ## at line (A)
must be the operator. Right? If so, the following
description in the example must be incorrect:
In other words, expanding hash_hash produces a new
token, consisting of two adjacent sharp signs, but
this new token is not the catenation operator.
This description certainly says that ## is a token, but
it is not the operator.
Well, for the above description, should we read like
the following sentence?
...this new token is the operator as
preprocessing-token, but does not function as the
catenation operator.
Even if so, this situation violates the Constraints of
subclause 6.1.5 "Operator"(page 45 in draft 9) unless
"##" in line (A) is considered as an operator:
The operators # and ## shall occur in macro-defining
preprocessing directives only.
If we think a case that "##" is not a single
preprocessing-token, then a behavior of this example must
be undefined because of a paragraph 3 of subclause 6.8.3.3
"the ## operator" (page 130 in draft 9):
If the result is not a valid preprocessing token,
the behavior is undefined.
Anyway, whichever we choose, that is, the violation of
the constraints or the undefined behavior, this example
is not suitable for the example of the standard C.
6) Incorporation of Amendment 1
Some important description about resetting the orientation
of the stream seems to be necessary to add to the existing
functions like fsetpos(), fseek(), rewind() and so on. In
order to incorporate Amendment 1 correctly into the revised
standard C it is necessary to review the current draft from
more precise viewpoint. Japan will provide the review
result in the near future from the multibyte character
user's standpoint.
2. Editorial Comments
---------------------
1) The reference ISO/IEC 646:1983 must be ISO/IEC 646:1991.
Paragraph 1 of clause 2 (page 2 in draft 9):
The normative reference for ISO 7-bit codes character set is
defined as ISO 646:1983. That is old. It must be the
latest one ISO/IEC 646:1991.
2) Locale-specific behavior
Paragraph 4 of Clause 4 (page 6 in draft 9):
The description "an implementation shall be accompanied by a
document that defines all implementation-defined
characteristics and all extensions." should also mention
"the locale-specific behavior" which is defined in the
subclause 3.13.
3) The term "English alphabet" should be "Latin alphabet.
Paragraph 3 of clause 5.2.1 (page 15 in draft 9)
The term "English alphabet" described in paragraph 3 of
clause 5.2.1 should be replaced by the term "Latin alphabet"
in order to clarify that the alphabetical characters listed
in 5.2.1 are same one which are defined in ISO/IEC 646 IRV.
4) Terminology of a null character
A many variety of the representation of "null character"
is used in the draft 9.
For example,
- A byte with all bits zero, subclause 5.2.1.2 (page 17)
- '\0', subclause 6.1.3.4 (page 43)
- code of value zero, subclause 6.1.4 (page 44)
- \0 escape sequence, footnote 33 (page 44)
- zero-valued code, subclause 6.5.7 (page 104)
- code value zero, subclause 7.1.1 (page 139)
- code with value zero, subclause 7.13.8.1 (page 277)
- terminating zero code, subclause 7.13.8.1 (page 278)
So, they should be represented by using a same term.
5) Placemaker should be included in preprocessing token.
Paragraph 1 (syntax) of Subclause 6.1 (page 26 in draft 9):
Placemaker defined in 6.8.3.2 is not included in
the syntax of preprocessing token. It should be included.
6) Wrong references
There are a lot of references which points to wrong
subclauses. Please correct them. The following is a list of
such a kind of wrong references as far as we know:
- 6.1.2.4, page 31
Allocated storage is described in 7.12.3 -> 7.13.3
- 6.1.3.4, page 43
the mbtowc function(7.12.7.2) -> 7.13.7.2
- 7.2.1.1, page 146
the abort function(7.12.14.1) -> 7.13.14.1
- 7.3, page 147
EOF(7.11.1) -> 7.12.1
Footnote 121. See "future library directions" (7.18.2) -> 7.19.2
- 7.5.1.1, page 161 and 162
Footnote 125. See "future library directions" (7.18.3) -> 7.19.3
(7.11.6) -> (7.12.6)
(7.12.7) -> (7.13.7)
(7.12.8) -> (7.13.8)
(7.12.1) -> (7.13.1)
(7.13.4.3) -> (7.14.4.3)
(7.14.4.5) -> (7.15.3.5)
(7.13.4.5) -> (7.14.4.5)
- 7.17.2.2, page 302
(4.5.2.1) -> 7.3.1
- 7.17.2.2.2, page 302
(4.5.2.1) -> 7.17.2
Index is also having wrong subclause numbers. Please
maintain the index correctly also.
7) Needs the Rationale for the type-qualifier restrict.
Paragraph 1 of subclause 6.5.3 (page 90 in draft 9):
An introduction of the new type-qualifier restrict is one of
the significant changes to the standard C so that the clear
rationale is necessary for the user and implementor of the
standard C.
8) New syntax of designator is not included in Syntax Summary.
Paragraph 1 of subclause 6.5.7 (page 101 in draft 9) and
Annex B "Language Syntax Summary" (page 353 in draft 9):
New syntax designator and related syntax are not included in
the Annex B "Language Syntax Summary". It must be included.
(Generally speaking, the Annex B should be revised along
the draft standard.)
9) A typo in example 10 of "6.5.7 initializer"
Paragraph 23 of subclause 6.5.7(example #10) (page 107 if
draft 9):
"struct { init a[3], b; } w[] ="
should be changed to
"struct { int a[3], b; } w[] ="
10) Macro replacement
Paragraph 3 of subclause 6.8.3 (page 128 if draft 9):
A description "may be redefined" of paragraph 3 of subclause
6.8.3 should be changed to "shall not be redefined by
... unless ..." like the paragraph 2.
11) Definitions of terms of the library clause
Subclause 7.1.1 (page 139 in draft 9):
Definitions of terms of the library clause (subclause 7.1.1)
should be incorporated into the clause 3 "Definitions and
conventions."
12) Example of implicit declaration
Paragraph 3 (example) of subclause 7.1.7 (page 145 in
draft 9):
ISO 9899 has an example of implicit declaration in
subclause "7.1.7 use of library functions." In draft
9, however, the example is removed. Of course, "implicit
declaration" can not be recommended strongly to users, but
the draft standard says explicitly "... it is also
permissible to declare the function, either explicitly or
implicitly." Therefore we think it is not necessary to
remove the example. Please add the example to the
standard.
13) Missing a footnote 155 in "7.8 complex arithmetic <complex.h>"
Paragraph 2 of subclause 7.8 (page 201 in draft 9):
A description corresponding to the footnote 155 is
missing.
14) A double argument for the conversion specifier
Subclause 7.12.6.1 (page 232 - 233 in draft 9) and
subclause 7.18.2.1 (page 308 - 309 in draft 9):
In the description about the conversion specifier f, F, e,
E and G of the function f[w]printf,
"a double argument representing a floating-point number
is..."
should be changed to
"a double argument representing a normalized
floating-point number is..." ^^^^^^^^^^
in order to clarify the range and the definition of the
double argument.
15) Needs a rationale of changes of some values.
Paragraph 14 (Returns) of subclause 7.12.6.1 (page 236 in
draft 9):
In "Returns" of "7.12.6.1 the fprintf function", "the
minimum value for the maximum number of characters produced
by any single conversion" was changed of 509 (in ISO 9899)
to 4095 (in draft 9). We can not figure out the reason
why this value was changed. So we need a rationale
document which describes the reason.
Subclause 5.2.4.1 translation limits (page 18 - 19 in
draft 9):
We need a rationale document about the changes of
translation limits also.
16) What is "additional locale-specific subsequence forms"
of strto*() function?
Description of subclause 7.15.1.* (strto*) (page 260 to 266
in draft 9):
All of function strto*() have the following description:
In other than the "C" locale, additional
locale-specific subsequence forms may be accepted.
We, however, can not figure out the additional
locale-specific subsequence forms in other than the "C"
locale. Please add the example or make a rationale document
which describe the purpose of the above description.
17) Typo in footnote 190
Footnote 190 (page 261 if draft 9):
stdtod -> strtod
18) Typo in "7.13.1.9 the strtoll function"
Synopsis of subclause 7.13.1.9 (page 264 in draft 9):
"Strtol" should be changed
to "strtoll".
19) Typo in "7.17.3.2.2 the towctrans function"
Paragraph 2 of subclause 7.13.3.2.2 (page 304 in draft 9):
"... same as during the call to wctrans that returned
the value desc."
should be changed to
"... same as during the call to towctrans that returned the
value desc." ^^^^^^^^^
20) Typo in example #2 of "7.18.2.2 the fwscanf function"
Paragraph 21 (example #2) of subclause 7.18.2.2
(page 317 in draft 9):
"Will assign to i the value 56 and to x the value 7.10.0.
will skip ..."
should be changed to
"will assign to i the value 56 and to x the value 789.0
will skip ..." ^^^^^
21) Annex I.5 "Common Extension" should be reconsidered.
Annex I.5 (page 426 if draft 9):
A purpose of the existence of Annex I.5 "Common Extension"
is not clear. We think each of the extensions of Annex I.5
should be moved to the appropriate clause of the normative
part of the standard or a normative Annex by using the verb
"may." And the content of each extension should be
reviewed from the viewpoint of the current trend of C
language.
____________________ end of SC22 N2541 _____________________________