JTC1/SC22/WG14 N985

Document: SC22/WG14 N985
Date: 17-Oct-2002

An email today has reminded me that the WG14 is in the middle of reviewing
various of my DRs. So I've taken a quick look at the current draft
responses and made some comments. I hope these can be fed into the
discussions, and my apologies for leaving it so late.

DR219:

The implications of the committee discussion are that in the following code:

    struct s { char c; int i; long l; double d; } s = { 1, 2, 3, 4 };
    void *p1 = malloc (sizeof s); assert (p1);
    void *p2 = malloc (sizeof s); assert (p2);
    void *p3 = malloc (sizeof s); assert (p3);
    memcpy (p1, &s, sizeof (s));
    memcpy (p2, (void *) &s, sizeof (s));
    memcpy (p3, (char *) &s, sizeof (s));

p1 has the effective type "struct s", p3 has the effective type "char []",
and p2 presumably has the effective type "struct s" as well. Is this
correct and intended by the committee?


DR230:

The proposed wording would mean that, whenever an int appears in an
expression, it has to be converted to an int! This is a no-op, but is it
desirable? If this change is made, perhaps insert just before "If an" in #2
the words "Except where the type is int or unsigned int" or something like
that.

The "wider issue" would be a mistake to address. Even though the members of
an enumeration are limited to the range of int, an enumerated type could be
compatible with (say) unsigned long long. The present wording gets this
right, where as the suggested wording breaks it: for example, if X has such
a type, ~X currently has the same type whereas the proposal would make ~X
have the type unsigned long long.


DR246:

I don't agree with the response. In particular, if the declarator is for an
incomplete type, "completed" has two different meanings. It would be easy
to fix this as an editorial change in the next TC.


DR247:

Is the analogous change required in 3.4.1?


DR257:

In relation to the last part, is there a reason to require a new DR rather
than just to take action based on this one?


DR264:

The proposed committee response fails to address most of the issues in the
DR. In particular, rephrasing the issues:

(1) I can see nothing in the Standard that requires:
    isprint('!')
to be non-zero.

(2) I can see nothing in the Standard that requires either of:
    islower('!')
    isspace('!')
to be zero.

(and the same for the other 28 characters from " to ~).


DR267:

Related to these, 7.25.2.1 has a "forward" reference to 7.24.6.1.2.


DR268:

Possible alternative wording:

    If control jumps from outside an iteration statement to within the loop
    body, the following shall apply:
    - The code jumped over, including the controlling expression(s) of a
      while or for statement, are not evaluated when the jump happens.
    - The subsequent effect of a jump statement or of reaching the end of
      the loop body shall be the same as if the jump had not happened and
      the loop body was entered by execution of the iteration statement;
      in particular:
      - a break statement shall terminate execution of the iteration
        statement;
      - a continue statement or reaching the end of the loop body shall
        cause the controlling expression of a while or do statement, or
        the expressions expr-3 and then expr-2 of a for statement, to be
        evaluated; if the controlling expression does not compare equal
        to 0, the loop body is executed again from its beginning.


DR274:

Based on the committee discussion, I propose the new paragraph 7.21.1#3:

    For all functions in this subclause, each character shall be
    interpreted as if it had the type /unsigned char/ (and therefore
    every possible object representation is valid and has a different
    value).

Alternatively, remove the text before the first comma and then append the
remainder to #2.


DR277:

The intent is *not* clear enough, since the text can be parsed in two
different ways. Given the rest of the response, a minimal wording change
would be:

    ... declare identifiers which denote objects and which have storage ...


-- 
Clive D.W. Feather  | Work:  <clive@demon.net>   | Tel:  +44 20 8371 1138
Internet Expert     | Home:  <clive@davros.org>  | Fax:  +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |