JTC1/SC22/WG14
N786
Document ISO/WG14 N786
J11/97-
Comments on C9X draft 10
========================
Japan reviewed the C9X draft 10 mainly from the viewpoint of
the consistency with ISO 9899 Amendment 1. This paper
describes the result of the review.
1. Comments from the viewpoint of incorporation of "Amendment 1"
1.1 <% and %> are punctuators, not operators
@ Paragraph 4 in "6.1.5 Operators"
Two tokens <% and %> are described in "Semantics" of the
subclause "6.1.5 Operators", however, they are NOT the
operators. On the other hand, there is no description
of the semantics about the punctuators <% and %> in the
subclause "6.1.6 Punctuators." That is, the description
about the semantics of the punctuators <% and %> should
be moved from the subclause "6.1.5 Operators" to the
subclause "6.1.6 Punctuators."
1.2 Some editorial errors in f[w]printf/f[w]scanf
@ Conversion specifier g, G in "7.12.6.1 fprintf" (Page 235)
Need to add the description:
"A double argument representing an infinity or Nan is
converted in the style of an f or F conversion
specifier."
at the end of the description of the conversion
specifier g, G like the fwprintf function(7.18.2.1,
page 312).
@ Footnote 175 (Page 235)
Need to insert the line "16p-1 > bn" at the second line
of the footnote 175 like the footnote 214(page 312).
@ Paragraph 8 in "7.12.6.1 fprintf" (Page 237)
Need to change the sentence
from
"...(except for an array of character type using %s
conversion, or a pointer using %p conversion)"
to
"...(except for an array of char type using %s
conversion, an array of wchar_t type using %ls
conversion, or a pointer using %p conversion)"
like the description of the function fwprintf
(7.18.2.1, page 314).
@ Paragraph 4 in "7.12.6.2 fscanf" (Page 239)
Need to add the description:
"...(if an encoding error occurs or due to the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
unavailability of input characters)..."
in the paragraph 4 like the description of the
function fwscanf (7.18.2.2, page 315).
@ Item 4 of Paragraph 4 in "7.18.2.1 fwprintf" (Page 310)
The location of the sentence:
"An optional l(ell) specifying that a following c
conversion specifier applies to a wint_t argument; an
optional l specifying that a following s conversion
specifier applies to a pointer to a wchar_t argument;"
in item 4 of paragraph 4 in "7.18.2.1 fwprintf" (page
310) should be rearranged just like the paragraph 4 in
"7.12.6.1 fprintf" (page 233).
Note: The location of the above sentence in fprintf is
better than fwprintf.
@ Examples in Paragraph 15 of "7.18.2.1 fwprintf" (Page 315)
The character string "pi" should be printed as a Greek
character like the example of "7.12.6.1 fprintf" (page
238).
@ Paragraph 3 in "7.18.2.1 fwprintf" (Page 315)
The description:
"Each conversion specification is introduced by a %."
should be changed to
"Each conversion specification is introduced by the
wide character %."
like the representation "the character %" described in
paragraph 3 of "7.12.6,1 fprintf" (page 239).
@ Item 3 of Paragraph 3 in "7.18.2.2 fwscanf" (Page 316)
The location of the sentence:
"The conversion specifiers c, s, and [ shall be
preceded by l if the corresponding argument is a
pointer to wchar_t rather than a pointer to a
character type."
in item 3 of paragraph 3 in "7.18.2.2 fwscanf" (page
316) should be rearranged just like the paragraph 3 in
"7.12.6.2 fscanf" (page 239).
Note: The location of the above sentence in fscanf is
better than fwscanf.
@ Paragraph 8 in "7.18.2.2 fwscanf" (Page 316)
[ is missing. The description should be:
"...unless the specification includes a [, c or n
specifier." ^^
like the paragraph 8 in "7.12.6.2 fscanf" (page 240).
1.3 Missing references to footnote 221 in v[s]wprintf
@ Paragraph 2 in "7.18.2.8 The vwprintf function"
@ Paragraph 2 in "7.18.2.9 The vswprintf function"
Need to add the reference to the footnote 221 at the end
of the sentence "The v[s]wprintf function does not
invoke the va_end macro." like the description of the
function vfwprintf (7.18.2.7).
Note 1: The original Amendment 1 is also missing this
reference, however, it should be added just
like the vprintf and vsprintf.
Note 2: A reference to the footnote 185 need to be
added to the description of the vsnprintf
function(7.12.6.11).
1.4 The parameters of wcstod should be restricted-qualified
@ Paragraph 1 in "7.18.4.1.1 The wcstod functions"
In the synopsis of "7.18.4.1.1 The wcstod functions",
two parameter "nptr" and "endptr" should be
restricted-qualified like other functions described in
the subclause "7.18.4.1 Wide-string numeric conversion
functions."
1.5 The description of the {str,wcs}tod function is not
correct for "INF", or "NAN"
@ Paragraph 3 in "7.13.1.5 The strtod function"
@ Paragraph 3 in "7.18.4.1.1 The wcstod functions"
The description of the {str, wcs}tod functions:
"The subject sequence contains no [wide] characters if
the input [wide] string is empty or consists entirely of
white space, or if the first non-white-space [wide]
character is other than a sign, a digit, or a
decimal-point [wide] character."
is not correct if the subject sequence is INF, INFINITY,
NAN, or NAN(n-[w]char-sequence opt). Therefore, the
above description should be corrected to some suitable
representation for INF and NAN.
2. Amendments to the comments with the Japanese vote for
ISO/IEC JTC1/SC22 N 2444 (see ISO/IEC JTC 1/SC22 N2541)
2.1 Drop the editorial comment #2-19
> 2. Editorial Comments
> 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." ^^^^^^^^^
We found out that the description of "7.17.3.2.2" of draft 10
is correct and the description of the corresponding part
in Amendment 1 is incorrect. Therefore Japan drops this
editorial comment.
2.2 Drop the request #1-4
> 1. Technical Comments
> 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.
After internal long discussion in Japan, we reached the
result "the current description of "5.2.1.2" in draft
10 should be left alone." That is, we now think there is
no need to change the paragraph 1 of subclause 5.2.1.2
of draft 10. However, we feel that this part will cause
some problem in future. So, we want to propose to add a
footnote to this description in order to indicate the
correct interpretation. But, unfortunately, we now do
not have a good proposal of a description of footnote.
Shortly speaking, Japan drops the technical comment
#1-4, but Japan will propose to add a footnote in future.
3. Miscellaneous comments
3.1 Example of "6.7.1 Function definitions" is incorrect
@ Paragraph 11 in "6.7.1 Function definitions"
In Examples 1 of "6.7.1 Function definitions":
"Here int a, b; is the declaration list for the
parameter, which may be omitted because those are the
defaults."
This sentence is old, and incorrect in C9X because
the implicit int in declarations is no more permitted in
the current draft of C9X. Therefore the above
description need to be removed.
3.2 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:
@ "4. Compliance" (Page 6)
<stdarg.h> (7.10) -> (7.11)
<iso646.h> (7.15) -> (7.16)
@ "Paragraph 5 in 7.12.1" (Page 221)
7.11 -> 7.12
7.11.3 -> 7.12.3
@ "Forward references in 7.12.3" (Page 225)
7.12.4.3 -> 7.13.4.3
7.11.7.1 -> 7.12.7.1
7.11.5.3 -> 7.12.5.3
7.11.7.3 -> 7.12.7.3
7.11.5.5 -> 7.12.5.5
7.11.5.6 -> 7.12.5.6
7.17.3.1 -> 7.18.3.1
7.17.3.3 -> 7.18.3.3
7.17.6 -> 7.18.6
7.17.6.3.2 -> 7.18.6.3.2
7.17.6.3.3 -> 7.18.6.3.3
@ "Forward references in 7.12.6.2" (Page 246)
7.12.1.4 -> 7.13.1.5
7.12.1.5 -> 7.13.1.8
7.12.1.6 -> 7.13.1.10
7.17.6 -> 7.18.6
7.17.6.3.3 -> 7.18.6.3.3
@ "Paragraph 1 in 7.18.6.3" (Page 348)
7.12.7 -> 7.13.7
@ "Paragraph 1 in 7.18.6.4" (Page 350)
7.12.8 -> 7.13.8
3.3 Missing LLONG_{MIN, MAX} and ULLONG_MAX in Annex E
@ Annex E
LLONG_MIN, LLONG_MAX and ULLONG_MAX are missing in Annex E.
One more small comment:
@ 7.12.2 Streams
Need the Forward references to freopen(7.12..5.4),
fwide(7.18.3.10), mbstate_t(7.18.1), fgetpos(7.12.9.1),
and fsetops(7.12.9.3).
Makoto Noda
------
> Subject: (c.wg 5751) (SC22WG14.4757) Japanese Comments on Amendment 1 and draft 10
> Comments on C9X draft 10
> ========================
At 22:51 21/10/97 +0900, you wrote:
>
>Japan reviewed the C9X draft 10
>3.2 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:
Can I suggest consideration of the mechanism Andrew
Koenig is using for C++: NAME clauses. Cross references
can then be made by name, and then numbers computed properly
by a pre-processor.
Users of C9X will also have the problem of
changed clause numbers: using names will allow clauses in
future documents to be refered to with less ambiguity.