Subject: SC22 N2618 - Comment Disposition on CD 9899 - C

From: "william c. rinehuls" <[email-masked]>
Date: Mon, 1 Dec 1997 11:49:29 -0500 (EST)

_________________ beginning of title page ______________________________
ISO/IEC JTC 1/SC22
Programming languages, their environments and system software interfaces
Secretariat:  U.S.A.  (ANSI)

ISO/IEC JTC 1/SC22
N2618

TITLE:
Disposition of Comments Report on CD Registration for CD 9899: Information
technology - Programming languages - Programming Language C (Revision of
ISO/IEC 9899:1993)

DATE ASSIGNED:
1997-11-25

SOURCE:
Secretariat, ISO/IEC JTC 1/SC22

BACKWARD POINTER:
N/A

DOCUMENT TYPE:
Disposition of Comments Report

PROJECT NUMBER:
JTC 1.22.20.01

STATUS:
N/A

ACTION IDENTIFIER:
FYI

DUE DATE:
N/A

DISTRIBUTION:
Text

CROSS REFERENCE:
SC22 N2444, N2541

DISTRIBUTION FORM:
Def

Address reply to:
ISO/IEC JTC 1/SC22 Secretariat
William C. Rinehuls
8457 Rushing Creek Court
Springfield, VA 22153 USA
Telephone:  +1 (703) 912-9680
Fax:  +1 (703) 912-2973
email:  [email-masked]

_____________________ end of title page; beginning of report ___________

                      Disposition of Comments Report   
                  for CD Registration Ballot for CD 9899:
Information technology - Programming languages - Programming Language C
                      (Revision of ISO/IEC 9899:1993)

WG14 responses are labeled with a "WG14:" on the right hand margin.

Country: Denmark

The document does not have a number of required components.
DS is missing:

1. POSIX alignment on internationalization functionality

WG14: The Committee has discussed this issue, and believes that the
      POSIX alignment has been achived, in the version of the WD that
      will be forwarded on for CD Ballot.  The informed Delegate from
      Denmakr has been unable to attend the last two meetings. 

2. POSIX alignment with strftime()

WG14: The Committee has discussed this issue, and believes that the
      strftime library function as currently in the WD is aligned 
      with POSIX.

3. Basic IO functionality

WG14: The Committee discussed this topic, experts from the UDI group
      were asked to present their work in this areana.  UDI has been
      working with IEEE.  The consenus within the Committee is that 
      this not currently ready to incorporate in the C9X WD.  The 
      Committee has asked the maintainer of the WG14 e-mail reflector 
      to setup a special e-mail reflector.

4. Boolean type capabilities

WG14:  This feature has been added to the WD.

Country: Japan  ( was not in attendence )

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.

WG14: The Committee believes that the current WD is specifing current
      pracitice.  The Committee also believes that the benifit to the user
      community out weights the cost of implementation for this feature.

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.

WG14:  The Committee consensus is that there will be users if the type
       is made available.  The consensus of the Committee is not to
       have optional features if possible.

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. 

WG14:  The Committee discussed this, and believes that this feature
       is  currently existing practice.  The consensus of the Committee
       is that the simple interface of this function is usefull to the
       user community.

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. 

WG14: This comment was withdrawn.

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.

WG14:  The current WD has new preprocessor token wording, that 
       the Committee believes make the WD clearer in the area.  
       The example is correct.

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.

WG14: These are addressed in this document, see the part labeled
      "Extension to CD Registation comments".

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.

WG14: The WD will be corrected.

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.

WG14: The WD will be corrected.

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.

WG14: The WD will be corrected.

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.

WG14: The Committee discussed this issue, and reached the consensus
      that a more detailed proposal would be needed to make such a 
      major change.

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.
   
WG14:  The "placemarker" preprocessing tokens are conceptually 
       introduced during translation phase 4 and are conceptually 
       removed before the end of phase 4; their only function is 
       to ensure that empty macro arguments are distinct entities 
       during macro replacement, rather than vanishing too soon.
       Because "placemarker" preprocessing tokens cannot exist 
       in the program source file, it would be inappropriate and 
       confusing to show them in the formal grammar.

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. 

WG14:  The reference problem has been addressed, and the Committee
       is working on the index problems.

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.

WG14:  There will be rationale for this in the Rationale document.  
       The Rationale document will be available by the FCD ballot.

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.)
  
WG14:  Annex B has been updated.

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[] ="

WG14:  This has been changed as suggested.

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.

WG14:  This has been changed as suggested.

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."

WG14:  The Committee discussed this, the concensus was that the 
       terms defined in Subclause 7.1.1 pertained to the Library
       Clause only.  The terms defined in Clause 3 pertain to the
       entire Standard.

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.

WG14:  This has been addressed in the current version of the
       WD.

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.

WG14:  This has been addressed in the current version of the
       WD.

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.

WG14:  The Committee discussed this comment, and came to the 
       consensus that this is not an editoral issue, some floating
       point arithmetics support denormal numbers and infinities.
       There will need to be a detailed proposal to support this 
       change.

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.

WG14:  The rationale for this can be found the Plano Minutes
       WG14 N396.  The old translation limits are from a
       64K conceptual machine, the new translation limits are
       for a 500k conceptual machine.

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.

WG14:  Rationale will be added to the Rationale Document.

17) Typo in footnote 190

   Footnote 190 (page 261 if draft 9):

   stdtod -> strtod

WG14:  This typo has been changed.

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".

WG14:  This typo has been changed.

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."                    ^^^^^^^^^

WG14: This comment was withdrawn by the Japanese.

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 ..."                                    ^^^^^

WG14: This has been corrected.

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.

WG14:  The Committee believes that this annex has value.  It informs
       the user, in one place, of all the common extensions.  The
       Committee consensus is that this information needs to be
       in an annex, and not in the standard text.

      Extension to CD Registation comments.
     ---------------------------------------

Japanese Comments that pertain to CD Registration comment number 
6) Incorporation of Amendment 1.

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.

WG14 responses are labeled with a "WG14:" on the right hand
margin.

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."

WG14: This issue has been addressed, see WG14 N672

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).

WG14: The Committee discussed this issue, the WD  will be 
      changed along the lines suggested.

    @ 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). 

WG14: This format issue has been fixed.

    @ 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).

WG14: The Committee discussed this issue, the WD  will be 
      changed along the lines suggested.

    @ 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).

WG14: The Committee discussed this issue, the WD  will be 
      changed along the lines suggested.

    @ 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.

WG14: The Committee discussed this issue, the WD  will be 
      changed along the lines suggested.
     
    @ 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).

WG14:  This change was made to the WD.

    @ 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).

WG14: The Committee discussed this issue, the WD  will be 
      changed along the lines suggested.

    @ 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.

WG14: The Committee discussed this issue, the WD  will be 
      changed along the lines suggested.

    @ 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).

WG14: The Committee discussed this issue, the WD  will be 
      changed along the lines suggested.

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).

WG14: The Committee discussed this issue, the WD  will be 
      changed along the lines suggested.

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."

WG14: The Committee discussed this issue, the WD  will be 
      changed along the lines suggested.

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.

WG14: The Committee discussed this issue, the WD  will be 
      changed along the lines suggested.

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.

WG14: The Committee discussed this issue, the WD  will be 
      changed along the lines suggested.

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

WG14: All references have be fixed and reviewed.

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.

WG14: These will be added to the Annex.

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).

WG14: The change as suggested will be made.  Note fsetops will 
      be fsetpos.

_____________________ end of SC22 N2618 _______________________________