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) (7.10) -> (7.11) (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.