ISO/ IEC JTC1/SC22/WG14 N942

Subject: (SC22WG14.8335) issues of C99  from Japan
Date: Wednesday, April 18, 2001 3:46 PM

WG14,

In review process of C99, Japan has had several concerns and issue about 
description and specification of C99.  Below is the list of such items.
Japan needs some response to each items one by one  from WG14.
Would you please discuss and consider them?   

Thak you,
Makoto Noda, a chair of "JIS C" 



---------------------------------------------------------------
a) 6.2.6.2 Integer types       [change request to 9899:1999]

   >     [#1] For unsigned integer types other  than  unsigned  char,
   >     the  bits of the object representation shall be divided into
   >     two groups: value bits and padding bits (there need  not  be
   >     any  of  the  latter).   If there are N value bits, each bit
   >     shall represent a different power of 2 between 1  and  2N-1,
   >     so   that   objects   of  that  type  shall  be  capable  of
   >     representing values from 0  to  2N-1  using  a  pure  binary
   >     representation;   this   shall   be   known   as  the  value
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   >     representation.   The  values  of  any  padding   bits   are
         ^^^^^^^^^^^^^^^
   >     unspecified.44)

   The sentence "this shall be known as the value representation."
   has been already discussed via SC22WG14 mailing list. 
   See (SC22WG14.8038) and (SC22WG14.8066).

   The term "shall" is well defined in the Standard,
   therefore Japan proposes to correct the above sentence to
   appropriate one.


---------------------------------------------------------------------
b) 6.4.2.2 Predefined identifiers  [need more information/explanation]

   >    [#1] The identifier __func__ shall be implicitly declared by
   >    the  translator  as  if,  immediately  following the opening
   >    brace of each function definition, the declaration
   >             static const char __func__[] = "function-name";
   >    appeared, where function-name is the name of the  lexically-
                                                          ^^^^^^^^^^
   >    enclosing function.60)
        ^^^^^^^^^^^^^^^^^^

   Japan does not understand the term "lexically-enclosing function"
   What is enclosing what?  Please give us some explanation
   about this.


---------------------------------------------------------------------
c) 6.4.5 String literals     [change request]

   >      [#3]  The  same  considerations apply to each element of the
   >      sequence in a character string  literal  or  a  wide  string
   >      literal  as if it were in an integer character constant or a
   >      wide character constant, except that the single-quote  '  is
   >      representable either by itself or by the escape sequence \',
   >      but the double-quote " shall be represented  by  the  escape
   >      sequence \".

   This paragraph does not provide any new specification.  It
   is just for information.  It should go to the footnote.


---------------------------------------------------------------------
d) 6.5.2.1  Array subscripting    [change request]

   >     [#3]  Successive subscript operators designate an element of
   >     a multidimensional array object.  If E is  an  n-dimensional
   >     array  (n>=2)  with  dimensions  iXjX...Xk,  then E (used as
                              ^^^^^^^^^^^^^^^^^^^^^
   >     other than an lvalue)  is  converted  to  a  pointer  to  an
   >     (n-1)-dimensional  array  with  dimensions  jX...Xk.  If the
                                         ^^^^^^^^^^^^^^^^^^^
   >     unary * operator is applied to this pointer  explicitly,  or
   >     implicitly  as  a  result of subscripting, the result is the
   >     pointed-to  (n-1)-dimensional   array,   which   itself   is
   >     converted  into  a  pointer if used as other than an lvalue.
   >     It follows from this that arrays  are  stored  in  row-major
   >     order (last subscript varies fastest).

   The term "dimensions" seems to be misused in this context.
   That is,  is "i×j×...×k" the dimension?  And also, the
   symbol "X" is not defined in anywhere.  
   Please reconsider the description of this paragraph.
   (Sorry, but we do not have any alternative description.)


---------------------------------------------------------------------
e) 6.5.16.1  Simple assignment                      [change request]

   >     [#1] One of the following shall hold:93)
   [...] 
   >       -- both operands are pointers to qualified or  unqualified
   >          versions  of  compatible types, and the type pointed to
   >          by the left has all the qualifiers of the type  pointed
                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^
   >          to by the right;

   "the qualifiers of the type" should be changed to the
   well defined term "the type qualifiers".


---------------------------------------------------------------------
f) 6.5.16.1  Simple assignment                      [need more clarification]

   >     [#3] If the value being stored in an  object  is  read  from
   >     another  object  that overlaps in any way the storage of the
   >     first object, then the overlap shall be exact  and  the  two
   >     objects  shall  have  qualified or unqualified versions of a
   >     compatible type; otherwise, the behavior is undefined.

   Does this paragraph say about only the context of "simple
   assignment"?  Or, says about more general context?  It is
   not clear.
   (I guess this restriction is limited to the context of
   the simple assignment because of the description of
   footnote 135.)


---------------------------------------------------------------------
g) 6.5.16.2  Compound assignment        [need more information]

    >    [#2]  For  the  other  operators,  each  operand  shall have
    >    arithmetic  type  consistent  with  those  allowed  by   the
                           ^^^^^^^^^^^^^^^^
    >    corresponding binary operator.

    Japan does not understand what condition(s) is(are)
    required to be "consistent  with those".
    Please give us more description and/or explanation about
    "consistent with".


---------------------------------------------------------------------
h)                                      [need more information]
   6.5.2.2  Function calls
   >     [#5] If the expression that denotes the called function  has
   >     type  pointer  to  function  returning  an  object type, the
   >     function call expression has the same type  as  that  object
   >     type,  and has the value determined as specified in 6.8.6.4.
   >     Otherwise, the function call has type void.  If  an  attempt
                                                      ^^^^^^^^^^^^^^^
   >     is made to modify the result of a function call or to access
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   >     it after the next sequence point, the behavior is undefined.
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

   6.5.15  Conditional operator
   >     [#4]  The  first  operand  is evaluated; there is a sequence
   >     point after its evaluation.  The second operand is evaluated
   >     only  if  the first compares unequal to 0; the third operand
   >     is evaluated only if the first  compares  equal  to  0;  the
   >     result   is  the  value  of  the  second  or  third  operand
   >     (whichever is evaluated), converted to  the  type  described
   >     below.92)   If  an attempt is made to modify the result of a
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   >     conditional operator or to access it after the next sequence
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   >     point, the behavior is undefined.
         ^^^^^^

   6.5.16  Assignment operators
   >     [#4] The order of evaluation of the operands is unspecified.
   >     If  an attempt is made to modify the result of an assignment
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   >     operator or to access it after the next sequence point,  the
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   >     behavior is undefined.

   6.5.17  Comma operator
   >     [#2]  The left operand of a comma operator is evaluated as a
   >     void  expression;  there  is  a  sequence  point  after  its
   >     evaluation.  Then the right operand is evaluated; the result
   >     has its type and value.94)  If an attempt is made to  modify
                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^                          
   >     the  result  of  a  comma operator or to access it after the
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   >     next sequence point, the behavior is undefined.
         ^^^^^^^^^^^^^^^^^^
  -------
  cf.   6.5.13  Logical AND operator  (&&)
        6.5.14  Logical OR operator   (||)

  h-1) Japan does not understand what kind of a situation is
       applied to 
         "if  an  attempt is made to modify the result of XXX
         or to access it after the next sequence point".
       Please give us some examples of that.

       We guess the following examples for such a situation:
           y = x + (x=1);
           y = (x=1) + (x=2);
       Is this right?       

  h-2) Which interpretation is correct?
       i) {to modify the result of XXX} or 
            {to access it after the next sequence point}
      ii) {to modify the result of XXX or to access it}
          after the next sequence point

  h-3) "6.5.13  Logical AND operator(&&)" and "6.5.14
       Logical OR operator(||)" do not have the description
       "if an attempt is made ..., the behavior is
       undefined".   
       We think there is no differences between the behaviors
       of "function call", conditional operator", assignment
       operators, "comma operator", and && and ||.
       Why && and || does not have the description?


---------------------------------------------------------------------
i) 6.6  Constant expressions            [need clarification]

   >     [#4]  Each  constant expression shall evaluate to a constant
   >     that is in the range of representable values for its type.

   If an overflow is occurred in computing the expression, or
   if the result of the expression is overflowed, is such an
   expression considered as a constant?
   Please make clear.


---------------------------------------------------------------------
j) 6.6  Constant expressions         [just a comment]

   >     [#9]  An address constant is a null pointer, a pointer to an
                                                      ^^^^^^^^^^^^^^^
   >     lvalue designating an object of static storage duration,  or
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   >     a  pointer  to  a  function  designator; it shall be created
   >     explicitly using the unary & operator or an integer constant
   >     cast  to  pointer  type,  or  implicitly  by  the  use of an
   >     expression of array or function type.   The  array-subscript
   >     []  and  member-access . and -> operators, the address & and
   >     indirection * unary operators, and pointer casts may be used
   >     in  the creation of an address constant, but the value of an
   >     object shall not be accessed by use of these operators.

   We think "a pointer to an lvalue designating an object"
   is better to be changed to "a pointer to an object" in
   order to understand more easily.


---------------------------------------------------------------------
k) 6.7.2.1  Structure and union specifiers  [need clarification]

   >     [#16]  As  a  special  case, the last element of a structure
   >     with more than one named member may have an incomplete array
   >     type;  this  is  called  a  flexible  array member. With two
   >     exceptions, the flexible array member  is  ignored.   First,
   >     the  size  of  the structure shall be equal to the offset of
   >     the last element of an otherwise  identical  structure  that
                                                      ^^^^^^^^^^^^^^^
   >     replaces   the  flexible  array  member  with  an  array  of
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   >     unspecified length.106)  Second, when a .  (or ->)  operator
         ^^^^^^^^^^^^^^^^^^
   >     has a left operand that is (a pointer to) a structure with a
   >     flexible array member  and  the  right  operand  names  that
   >     member,  it behaves as if that member were replaced with the
   >     longest array (with the same element type)  that  would  not
   >     make  the  structure  larger than the object being accessed;
   >     the offset of the array shall remain that  of  the  flexible
   >     array  member,  even  if  this would differ from that of the
   >     replacement array.  If this array would have no elements, it
   >     behaves  as  if  it  had  one  element  but  the behavior is
   >     undefined if any attempt is made to access that  element  or
   >     to generate a pointer one past it.

   Japan does not understand what is "structure that
   replaces the flexible array member with an array of
   unspecified length".  Especially, what is an array of "unspecified
   length"?   From footnote 106, we can *imagine*.
   However, we need more strict description about "structure that
   replaces the flexible array member with an array of
   unspecified length".   And we think a description or requirement
   about alignment of an array which is to be replaced to the
   flexible array member  should be added.
   Please consider above.


---------------------------------------------------------------------
l) 6.7  Declarations              [change request]

   >     [#7]  If  an  identifier  for  an object is declared with no
   >     linkage, the type for the object shall be  complete  by  the
   >     end  of its declarator, or by the end of its init-declarator
   >     if it has an initializer; in the case of function  arguments
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   >     (including  in  prototypes),  it  is  the adjusted type (see
   >     6.7.5.3) that is required to be complete.

   "In case of function arguments" should be changer to 
   "in case of function parameters".


---------------------------------------------------------------------
m) 6.7.3.1  Formal definition of restrict   [need more description]

   >     [#4] During each execution of B, let L be  any  lvalue  that
   >     has  &L based on P.  If L is used to access the value of the
   >     object X that it designates, and X is also modified (by  any
                                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^
   >     means),  then  the following requirements apply: T shall not
         ^^^(m-1)
   >     be const-qualified.  Every other lvalue used to  access  the
   >     value  of  X  shall also have its address based on P.  Every
                                                                ~~~~~
   >     access that modifies X shall be considered also to modify P,
         ~~~~~~~~~~~ ^^^^^^(m-1) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~(m-2) 
   >     for  the  purposes  of this subclause.  If P is assigned the
         ===================================(m-3)
   >     value of a pointer expression E that  is  based  on  another
   >     restricted pointer object P2, associated with block B2, then
   >     either the execution of B2 shall begin before the  execution
   >     of  B,  or  the  execution  of  B2  shall  end  prior to the
   >     assignment.  If these requirements are  not  met,  then  the
   >    behavior is undefined.

   m-1) Japan does not understand the meaning of "modify object X".
        Please give us some examples or more description
        about the meaning of "modify an object".

   m-2) Japan does not understand why P is modified when X
        is modified.

   m-3) Japan does not understand the meaning and the
        intention of the sentence "for the purpose of this
        subclause".  Please give us more description about
        that.

        And, which interpretation is correct?
         i) ... shall be considered ... for the purpose of this subclause.
        ii) ... modify P for the purpose of this subclause.


---------------------------------------------------------------------
n) 6.7.5.2  Array declarators        [need more description]

   >     [#5] If the size is an expression that  is  not  an  integer
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   >     constant  expression:  if  it  occurs  in  a  declaration at
         ^^^^^^^^^^^^^^^^^^(n-1)
   >     function prototype scope,  it  is  treated  as  if  it  were
   >     replaced by *; otherwise, each time it is evaluated it shall
   >     have a value greater than zero.  The size of  each  instance
   >     of  a  variable length array type does not change during its
   >     lifetime.  Where a size expression is part of the operand of
                          ^^^^^^^^^^^^^^^^(n-2)
   >     a  sizeof  operator  and  changing  the  value  of  the size
                                                             ^^^^^^^^
   >     expression would not affect the result of the  operator,  it
         ^^^^^^^^^(n-2)
   >     is  unspecified  whether  or  not  the  size  expression  is
                                            ^^^^^^^^^^^^^^^^^^^(n-2)
   >     evaluated.

  n-1) Japan does not understand what a kind of case is
       applied to "if the size is an expression that  is
       not  an  integer constant  expression".
       Please give us more description and/or a example of that.

  n-2) Please give us the clear definition of "size expression".

  In conclusion, Japan does not understand what is described in
  the above paragraph.


---------------------------------------------------------------------
o) 6.10.3  Macro replacement            [change request]

   >     [#4] If the identifier-list in the macro definition does not
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   >     end  with  an  ellipsis,  the number of arguments (including
         ^^^^^^^^^^^^^^^^^^^^^^^
   >     those arguments consisting of no preprocessing tokens) in an
   >     invocation  of  a function-like macro shall equal the number
   >     of parameters in the  macro  definition.   Otherwise,  there
   >     shall  be  more  arguments  in the invocation than there are
   >     parameters in the  macro  definition  (excluding  the  ...).
   >     There  shall  exist  a ) preprocessing token that terminates
   >     the invocation.

   >     [#12] If there is a ...  in the identifier-list in the macro
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   >     definition,  then  the  trailing  arguments,  including  any
   >     separating  comma preprocessing tokens, are merged to form a
   >     single item: the variable arguments. The number of arguments
   >     so  combined  is  such that, following merger, the number of
   >     arguments is one more than the number of parameters  in  the
   >     macro definition (excluding the ...).

   The definition "identifier-list" does not contain an ellipsis "...",
   therefore the above paragraphs should be corrected to some
   appropriate description.


---------------------------------------------------------------------
p) FN44/45       [just a comment]

   >     44)Some  combinations  of  padding  bits might generate trap
   >        representations, for example, if one  padding  bit  is  a
   >        parity bit.  Regardless, no arithmetic operation on valid
                         ^^^^^^^^^^
   >        values can generate a trap representation other  than  as
   >        part of an exceptional condition such as an overflow, and
   >        this  cannot  occur  with  unsigned  types.   All   other
   >        combinations  of  padding  bits  are  alternative  object
   >        representations of the value specified by the value bits.

   Japan is not sure whether or not "Regardless, ..." is a
   correct English.  (Of course, we are not native speakers,
   therefore if some native speakers guarantee that there is
   no problem, then we have no problem.)


---------------------------------------------------------------------
q) FN70              [change request]

   >     70)This paragraph renders  undefined  statement  expressions
   >        such as
   >                i = ++i + 1;
   >                a[i++] = i;
   >        while allowing
   >                i = i + 1;
   >                a[i] = i;

  "statement expression" should be corrected to "expression
  statement".   Right?


---------------------------------------------------------------------
r) FN76               [change request]

   >     76)Thus,  an  undeclared  identifier  is  a violation of the
   >        syntax.

   Footnote 76 is quoted in the Semantics, not the Syntax.  
   We think it should be "a violation of the semantics".


---------------------------------------------------------------------
s) FN83               [change request]

   >     83)Thus,  &*E  is  equivalent  to  E  (even  if  E is a null
   >        pointer), and &(E1[E2]) to  ((E1)+(E2)).   It  is  always
   >        true that if E is a function designator or an lvalue that
   >        is a valid operand of the unary  &  operator,  *&E  is  a
   >        function designator or an lvalue equal to E.  If *P is an
   >        lvalue and T is the name of an object pointer type, *(T)P
                                        ^^^^^^^^^^^^^^^^^^^^^^
   >        is  an  lvalue  that  has  a type compatible with that to
   >        which T points.
   > 
   >        Among the invalid values for dereferencing a  pointer  by
   >        the  unary  *  operator  are  a  null pointer, an address
   >        inappropriately aligned for the type  of  object  pointed
   >        to,  and  the  address  of an object after the end of its
   >        lifetime.

   What is "an object pointer type"?    There is no definition.
   It should be rewritten to other appropriate term.


--- end of text ---