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