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: | Tel: +44 20 8371 1138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | |