ISO/ IEC 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.