=========================================== Public Comment Number PC-UK0001 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1997-12-27 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Editorial change/non-normative contribution Committee Draft subsection: various Title: Errors in applying working papers to CD1 Detailed description: This document lists the errors that have been made applying my approved papers in CD1. They are listed in this Public Comment for the record. N672 has not been applied. The change to translation phase 2 in N673 has been made, but the footnote has been lost. 7.1.8p3 should read "... returns.", not "... return"; see N675 DR147 for details. The same correction is needed in annex C. Footnote 30 should read "... and is not compatible with either.", not "and it not compatible with either.". The change was introduced in N739 item 6a. 6.5.2p4 should read "... the specifier /int/ ...". The change was introduced in N739 item 10. 7.16.3.6p6 should read "%p", not "%P" (this was introduced in N674 part G). It is also inconsistent in its use of fonts - compare %B and %p. 7.11p3 has been misedited; it reads: ... which expand to positive integer constant expressions with type /int/ and distinct values that have type compatible ... which expand to positive integer constant expressions with distinct values that are the signal numbers ... and should read: ... which expand to constant expressions with distinct values that have type compatible ... which expand to positive integer constant expressions with type /int/ and distinct values that are the signal numbers ... The change was introduced in N773 item 9B. 6.3.15p4 to p6 have not been changed as required by N774 item 1. 6.5.2.3p4 should read "The type is incomplete[94]", not "The type is complete[94]". The change was introduced in N774 item 5. Footnote 227 is missing the last line: (char *) p < (char *) base + nmemb * size The change was introduced in N783 item 13. The changes relating to _exit() in N789 were omitted (at the discretion of the editorial committee). These will be resubmitted as a separate Public Comment. 7.16.1p1 should read "... and declares five types ...", not "... and declares four types ...". The change was introduced in N793. The comment within the pseudo-code in 7.16.2.6p3 is missing the last line, which should read: // if the offset cannot be determined. The change was introduced in N793, though this also seems to be missing that line. =========================================== Public Comment Number PC-UK0002 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1997-12-27 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Other: correction restoring original intent Committee Draft subsection: 6.5.2.1 Title: Padding in unions - wording adjustment Detailed description: 6.5.2.1p14 no longer makes sense. The words: were the structure or union to be an element of an array should be deleted. =========================================== Public Comment Number PC-UK0003 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1997-12-27 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Normative change to existing feature retaining the original intent Committee Draft subsection: 6.3.2.2 Title: Adjustment to permitted incompatible argument types Detailed description: The excepted cases in 6.3.2.2p5 were meant to be slightly less restrictive than the wording given. The second bullet point should read: - both types are pointers to qualified or unqualified versions of /void/ or of character types. In addition, paragraph 6 should be part of paragraph 5; it is easy to misparse the present arrangement. It could also be made easier by changing the first words of the paragraph to: Furthermore, if the function ... =========================================== Public Comment Number PC-UK0004 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1997-12-27 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.3.7 Title: Shift operators - wording tidy up Detailed description: Now that the term "width" is available, 6.3.7p3 could be reworded; the last sentence should read: If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined. =========================================== Public Comment Number PC-UK0005 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1997-12-25 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Normative change to existing feature retaining the original intent Committee Draft subsection: 3.18, 6.8.5 Title: Make #error have the desired effect Detailed description: Consider the program: #error foo int main(void) { return 0; } This does not violate any of 3.18p3: The implementation must successfully translate a given program unless a syntax error is detected, a constraint is violated, or it can determine that every possible execution of that program would result in undefined behavior. but clearly ought to. A reasonable way to fix this is to add to the end of 3.18p3: The implementation must not successfully translate a program that contains a #error preprocessing directive that is not part of a group that is skipped by conditional inclusion. =========================================== Public Comment Number PC-UK0006 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1997-12-27 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.1.4 Title: Clarification concerning overlapping string literals Detailed description: The first sentence of 6.1.4p6 does not fall into any of the three types of behavior. Better wording would be: It is unspecified whether these arrays overlap or not, provided that their characters have the appropriate values. =========================================== Public Comment Number PC-UK0007 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1997-12-27 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Other: outstanding problem Committee Draft subsection: 6.5.3.1 Title: Problem with restrict and string literals Detailed description: Consider the function call: fopen ("bar", "r"); Because both parameters of fopen() have restrict-qualified type, it is not permitted for the two strings to share storage. However, an implementation which shares string literals might do so, possibly without the programmer realizing that the situation happened (for example, the first parameter might be a macro defined in a makefile). The correct solution is to exempt string literals from the rules concerning restrict, but I am not familiar enough with the wording to try. =========================================== Public Comment Number PC-UK0008 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1997-12-29 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Other: moving normative text to a normative section Committee Draft subsection: Introduction, 1 Title: The definition of normative text should be normative. Detailed description: The Introduction contains the text: The introduction, the examples, the footnotes, the references, and the annexes are not part of this International Standard. However, this text is not normative, and so it is not clear what text is and is not normative. It is also wrong. Delete the sentence from the Introduction. Add a new paragraph 3 to clause 1: Annexes F and I are normative. The introduction, the examples, the footnotes, the references, and the remaining annexes are not part of this International Standard. =========================================== Public Comment Number PC-UK0009 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1997-12-29 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Inconsistency Committee Draft subsection: 7.16.3.6 Title: Lacuna in strftime() %z Detailed description: The description of %z does not say what to do if no time zone can be determined. After the parenthesized clause, insert the words: or no characters if no time zone is determinable. =========================================== Public Comment Number PC-UK0010 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1997-12-29 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Normative change to existing feature retaining the original intent Committee Draft subsection: 7.16.1 Title: _NO_LEAP_SECONDS should require a sensible value Detailed description: After the symbol _NO_LEAP_SECONDS in 7.16.1p2, add the comment: _NO_LEAP_SECONDS // must be outside the range [-3600, +3600] =========================================== Public Comment Number PC-UK0011 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1997-12-29 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Normative change to existing feature retaining the original intent Committee Draft subsection: 7.16.1 Title: require a type for _NO_LEAP_SECONDS and _LOCALTIME. Detailed description: At the end of 7.16.1p2 add the words: which are integral constant expressions with type /int/. =========================================== Public Comment Number PC-UK0012 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1997-12-29 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Inconsistency Committee Draft subsection: 7.16.1 Title: Fix definition of "broken-down time". Detailed description: The term "broken-down time" is clearly intended to refer to both the types "struct tm" and "struct tmx". Change the last part of 7.16.1p3 from: ... representing times; /struct tm/ which holds the components of a calendar time, called the /broken- down time/; and /struct tmx/ which is an extended version of /struct tm/. to: ... representing times; and /struct tm/ and /struct tmx/ which hold the components of a calendar time, called the /broken- down time/, in two slightly different ways. =========================================== Public Comment Number PC-UK0013 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1997-12-29 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Normative change to existing feature retaining the original intent Committee Draft subsection: 6.1.2.5, 6.5.2.1 Title: Cleanup of flexible array structure members. Detailed description: The concept of flexible array structure members, otherwise known as the "struct hack", has a number of minor problems that need fixing. Furthermore, there are some nasty implications when such a structure is used as a component of an aggregate type, this is forbidden. 6.1.2.5p17, bullet point 2, should read: A /structure type/ describes a sequentially allocated nonempty set of member objects (and, in certain circumstances, an incomplete array), each of which has an optionally specified name and possibly distinct type. 6.5.2.1p2, first sentence, should read: ... except that the last member of a structure with more than one named member may have incomplete array type; such a structure (and any union containing, possibly recursively, a member whose type is such a structure) shall not be the type of a member of a structure or of the element of an array. 6.5.2.1p15 should be replaced by: As a special case, the last member of a structure with more than one named member may have an incomplete array type. This is called a /flexible array member/, and the size of the structure shall be equal to the offset of the last member of an otherwise identical structure that replaces the flexible array member with an array of unspecified length [*]. When an lvalue whose type is a structure with a flexible array member is used to access an object, 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, then 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 that element. [*] The length is unspecified to allow for the fact that some implementations may give array members different alignments according to their length. Change the start of paragraph 16 to: Assuming that all arrays have the same alignment within structures, then after the declarations: struct s { int n; double d[]; }; struct ss { int n; double d[42]; }; the three expressions: In paragraph 17, change: /s1/ and /s2/ behave as if they had been declared as: to: the objects pointed to by /s1/ and /s2/ behave as if the latter two identifiers had been declared as: =========================================== Public Comment Number PC-UK0014 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1997-12-29 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Inconsistency Committee Draft subsection: 6.5.8 Title: problems with initializing unsigned char arrays. Detailed description: Consider the following declaration: unsigned char s [] = "\x80\xff"; The first element of the string literal has the value: (char) 128 and the second element has the value: (char) 255 If the type char is signed and CHAR_MAX is less than 128, these two expressions are implementation-defined. In particular, on a ones- complement implementation likely values are -127 and -0 respectively. When these are converted back to unsigned char during the initialization, then (if UCHAR_MAX is 255) they will be converted to 129 and 0 respectively. This is *not* intuitive. Append to 6.5.8p17: The value of each element is determined by converting the corresponding numerical representation of the mapped character, or the octal or hexadecimal escape sequence, directly to the array element type, not via the type char. Append to example 7 in 6.5.8p24: The declaration: unsigned char c [] = "\xFF"; is identical to: unsigned char c [2] = { 0xFF, 0 }; and not to: unsigned char c [2] = { (unsigned char)(char) 0xFF, 0 }; (the latter could be different if /CHAR_MAX/ is less than 255 and the implementation-defined value of the expression /(char) 0xFF/ is not equal to /254-UCHAR_MAX/). =========================================== Public Comment Number PC-UK0015 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1997-12-30 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Feature that should be included Committee Draft subsection: 5.2.4.2.1 Title: ensure int can hold all characters and EOF Detailed description: To eliminate a pathological case, append to 5.2.4.2.1p2: On a hosted implementation, INT_MAX shall be not less than UCHAR_MAX. =========================================== Public Comment Number PC-UK0016 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1997-12-30 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Normative change to intent of existing feature Committee Draft subsection: 6.1.1 Title: eliminate conditional keywords Detailed description: 6.1.1 makes the keywords "complex" and "imaginary" only be "reserved" if the header is included. This is a problem for two different reasons. Firstly, cautious programmers will assume that the keywords might be needed at some later date, for example by a system header that they have no control over. Therefore they will have to play safe and not use them. The less cautious may use them, and then be burnt later when such a change outside their control happens. Both cases bring the Standard into disrepute. Seeing that the decision has already been made to introduce new keywords, there is little benefit in this approach unless it is going to be more radical (for example, making complex types be unavailable on freestanding implementations). And, even so, there are better approaches. Secondly, the term "reserved" is being misused. This term (see 7.1.3) means that an identifier may not be redeclared. Keywords are not identifiers, and thus reservation is nonsense. In any case, the syntax does not allow a keyword to be used as if it were an identifier. Three alternatives are given here; my preference is for the third. Alternative 1: delete 6.1.1 paragraph 2. Alternative 2: if it is still viewed as desirable to make the names "complex" and "imaginary" available to programmers not using , then: * Change the keywords in 6.1.1 to __complex and __imaginary. * Add to 7.8 a new paragraph 4: The macro /complex/ is defined to be /__complex/. If and only if the macro /_Imaginary_I/ is defined, then the macro /imaginary/ is defined to be /__imaginary/. Notwithstanding the provisions of subclause 7.1.3, it is permitted to undefine the macros /complex/ and /imaginary/. Alternative 3: since complex types are basic to the language while imaginary types are an extension: * Change the keyword imaginary in 6.1.1 to __imaginary. * Add to 7.8 a new paragraph 4: If and only if the macro /_Imaginary_I/ is defined, then the macro /imaginary/ is defined to be /__imaginary/. Notwithstanding the provisions of subclause 7.1.3, it is permitted to undefine the macro /imaginary/. =========================================== Public Comment Number PC-UK0017 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-17 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Normative change to existing feature retaining the original intent Committee Draft subsection: 6.3.9 Title: fix pointer comparison Detailed description: DR 172 addressed a number of defects in the rules for pointer comparison, and the DR authors suggested new wording to fix this. This issue was also raised in WG14 papers N720 and N783. Following other changes in the Standard, this wording is no longer completely acceptable. Instead, replace 6.3.9 paragraphs 3 to 5 with the following text. The == (equal to) and != (not equal to) operators are analogous to the relational operators except for their lower precedence.[78] They yield 1 if the specified relation is true and 0 if it is false. The result has type /int/. For any pair of operands, one operator shall be true and the other false. If both of the operands have arithmetic type, the usual arithmetic conversions are performed. [[Insert the existing paragraph 5 here.]] Otherwise the operands are pointers; if one is a pointer to an object or incomplete type and the other has type pointer to a qualified or unqualified version of /void/, the former is converted to the type of the latter. Two pointers shall compare equal if both are null pointers, both are pointers to the same object (including a pointer to an object and a subobject at its beginning), the same element of an array object, or the same function, if both are pointers to one past the end of the same array object, or if one is a pointer to one past the end of one array object and the other is a pointer to the start of a different array object that happens to be immediately after it in the address space.[79] Otherwise they shall compare unequal. Prepend to footnote 79: Two objects may be adjacent in memory because they are adjacent elements of some larger array object, because they are adjacent members of a structure with no padding between them, or because they are unrelated and the implementation chooses to place them adjacent in memory. =========================================== Public Comment Number PC-UK0018 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-04 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.1.2.7, 6.3.1.1 Title: merge predefined identifiers into one place Detailed description: The concept of predefined identifiers is found in two separate places: 6.1.2.7 and 6.3.1.1. The latter location is, I believe, historical cruft from when __func__ was treated as a special entity. It would read better to merge the two sections into one, and 6.1.2.7 is a better location. Delete subclause 6.3.1.1. Replace subclause 6.1.2.7 by the following: 6.1.2.7 Predefined identifiers The identifiers described in the following subclauses shall be implicitly defined by the implementation. 6.1.2.7.1 The identifier __func__ [[Insert the body of the present 6.3.1.1 here.]] =========================================== Public Comment Number PC-UK0019 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-06 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Request for information/clarification Committee Draft subsection: 5.1.1.2, 6.3.1.1 Title: handling of characters not in the execution character set Detailed description: Consider the code extract: char *s = "\u30CE"; During translation phase 5 the universal character name is converted to a multibyte character. However, it is not stated what happens if the implementation does not have a representation for Katakana (30CE is within the Katakana range of annex I). Therefore it is implicitly undefined. Now consider the following translation unit: #include void fff (void); void \u30CE (void); int main (void) { fff (); \u30CE (); return 0; } void fff (void) { printf ("This is %s\n", __func__); } void \u30CE (void) { printf ("Hello world!\n"); } This is clearly strictly conforming (unless I've made an error :-). Now consider the trivial change: #include void fff (void); void \u30CE (void); int main (void) { fff (); \u30CE (); return 0; } void fff (void) { printf ("Hello world!\n"); } void \u30CE (void) { printf ("This is %s\n", __func__); } This is now undefined on any implementation that cannot represent the Katakana character set ! I have trouble believing that this was intended, and I certainly feel that, if it is retained, it should be flagged in the text of the Standard. =========================================== Public Comment Number PC-UK0020 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-03 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Editorial change/non-normative contribution Committee Draft subsection: 4 Title: Adjust wording of footnote 2 Detailed description: Footnote 2 is not particularly clear. Better wording would be: A strictly conforming program can use conditional features, such as those in annex F, provided that the use is guarded by an #ifdef directive with the appropriate macro. For example: [[followed by the existing example]] =========================================== Public Comment Number PC-UK0021 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-03 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Normative change to existing feature retaining the original intent Committee Draft subsection: 4 Title: Further requirements on the conformance documentation Detailed description: There are many things that the Standard requires to be documented, but not all of them are listed in 4p4. Change it to: An implementation shall be accompanied by a document that describes all features that this International Standard requires to be described by the implementation, including all implementation-defined characteristics and all extensions. =========================================== Public Comment Number PC-UK0022 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-03 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Inconsistency Committee Draft subsection: 5.1.1.2 Title: Translation phase 6 is inconsistent Detailed description: Change TP 6 in 5.1.1.2p1 to read: Adjacent character string literal tokens and wide string literal tokens are concatenated. =========================================== Public Comment Number PC-UK0023 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-03 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Inconsistency Committee Draft subsection: 6.5.2.1, 6.5.6 Title: Removing implicit int, further lacunae Detailed description: The requirement for a type specifier has been omitted from 6.5.2.1 and 6.5.6. In each case, add a constraint: At least one type specifier shall be given in each specifier-qualifier-list. =========================================== Public Comment Number PC-UK0024 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-03 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.1.2.5 Title: Replace footnote 25 Detailed description: Footnote 25 is unclear in context. A better description of the situation is in footnote 29. Replace the text of FN25 with that of FN29, and change all references to the latter to be references to the former. =========================================== Public Comment Number PC-UK0025 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-03 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.1.3.2 Title: clarify the explanation of the types of an integer constant Detailed description: 6.1.3.2p5 is rather difficult to read. Better would be to replace it with a table, like this: The type of an integer constant is the first one marked with an X in the corresponding column of the table in which its value can be represented: Suffix: - - U L L LU LL LL LLU Base: D O/H - D O/H - D O/H - signed int X X unsigned int X X signed long X X X X unsigned long X X X X signed long long X X X X X X unsigned long long X X X X X X /signed extended/ X X X /unsigned extended/ X X X /any extended/ X X X Notes: suffixes may be in either case, and where there are two suffixes, in either order. D = decimal O/H = octal or hexadecimal If an integer constant cannot be represented by any standard type in its list, it may be represented by an extended integer type if there is one that can represent that value. The type must be signed or unsigned if so indicated. Alternatively, the ad hoc nature of the present description could be replaced by one more structured: The type of an integer constant is the first one in the following list in which its value can be represented: /signed int/, /unsigned int/, /signed long int/, /unsigned long int/, /signed long long int/, /unsigned long long int/ and subject to the following restrictions: - if suffixed by /u/ or /U/, then omit the signed types - if decimal and not suffixed by /u/ or /U/, then omit the unsigned types - if suffixed by /l/ or /L/, then omit the first pair - if suffixed by /ll/ or /LL/, then omit the first two pairs If an integer constant cannot be represented by any of the types permitted by the above, it may be represented by an extended integer type if there is one that can represent that value and which has the same signedness as at least one of the permitted standard types. =========================================== Public Comment Number PC-UK0026 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-03 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.1.4 Title: improve the example of character string literals Detailed description: Append to 6.1.4p7, the example: When this is used to initialize a static array, the array has three members that are initialized to /18/, the value of /'3'/, and /0/ respectively. =========================================== Public Comment Number PC-UK0027 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-03 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Inconsistency Committee Draft subsection: 5.1.1.2, 5.2.1, 5.2.1.2, 6.1.2, 6.1.2.5, 6.8 Title: inconsistencies in use of "basic" and "extended" character sets and in their relationship to UCNs Detailed description: The Standard uses the terms "basic character set" and "extended character set" at various places. However, the exact meaning of these two is not clear, and this leads to confusion. Consider the UTF-8 encoding (codes from 0 to 127 are single byte, codes from 128 to 255 form part of multibyte characters with length from 2 to 5 bytes). There are five possible execution character sets: [1] The 95 characters required by 5.2.1p3, plus the null character. [2] The 128 single byte characters. [3] The 2**31 multibyte characters. [4] Set [3] minus set [1]. [5] Set [3] minus set [2]. (and corresponding source sets). It is unclear whether the "basic character set" means [1] or [2]. The use of the wording "at least the following members" in 5.2.1p3 implies that the basic set can be larger than [1]. On the other hand, if the term is taken to represent [2], then 5.1.1.2p2 would forbid using \u0040 to represent the @ sign, something which I do not believe was intended, since it means that the \u form would be forbidden for *all* characters in the implementation-defined "basic" set. Consideration of this and related matters has led me to believe that it is most useful to have terms for [1] and for [4], while on the other hand there is little or no need to refer to [2], [3], and [5]. Therefore "basic character set" should represent [1] and "extended character set" should represent [4]. To do this requires a number of changes. Replace 5.2.1p1, second sentence, by: Each set is further divided into a /basic/ set, whose contents are given by this subclause, and an /extended/ set, consisting of zero or more locale-specific members (which are not members of the basic set). In 5.2.1p3, delete "at least" in the first sentence, and in the fourth sentence change "In the execution character set" to "In the basic execution character set". Delete the last sentence of 5.2.1p3 ("If any other characters ... the behavior is undefined"). It is useless for several reasons: - If translation phase 1 is taken literally, all members of the extended character set are replaced by UCNs, which consist of members of the basic character set (this point is further addressed below). While some are converted back in translation phase 5, all such characters are included in the exemptions. - It does not allow for UCNs in identifiers. - If such a character was encountered, the preprocessing token it is in is either not converted to a token (in which case the sentence does not apply) or *is* converted; in the latter case, the constraint of 6.1p2 is violated and this sentence has no effect. Delete 5.1.1.2p2, and replace it by a constraint at the end of 5.2.1 (forming a new paragraph 6): Constraint A universal-character-name shall not specify (in either form) a character short identifier less than 00A0 other than the following: 0024 0040 0060 This is a more consistent position for the restriction, and it has the useful side effect of making it clear what the UCNs of the basic character set *are*. Replace 5.2.1.2p1, first bullet, by: - The basic character set shall be present and shall be encoded using single-byte characters. There is no longer a need to check for the shift states of comments, string literals, and so on, because during translation phase 1 these will have been converted to a stateless representation using UCNs. Therefore replace 5.2.1.2p2 by: If a source file does not consist of a valid sequence of multibyte characters, the behavior is undefined. In 6.1.2.5p2, replace "required source character set enumerated in 5.1.2" with "basic execution character set" (note that the execution set is more sensible in this context than the source set). The second sentence of 6.1.2p2 restricts UCNs in identifiers to those listed in annex H. If some other UCN appears, it is unclear whether the behavior is undefined, or whether the UCN is not part of the identifier. This is further complicated by the example in footnote 122. If the text appeared in a source file, by translation phase 4 it would be processed as: #define THIS\u0024AND\u0024THAT(a,b) ((a)+(b)) and so the replacement list *does* begin with a character required by subclause 5.2.1, and thus this is unambiguously a definition of the object-like macro THIS. However, this completely wrecks the whole point of 6.8p4 and FN122 (added in TC1). Replace the second sentence of 6.1.2p2 with: Only universal-character-names corresponding to the characters listed in annex I are nondigits.[20] and append to footnote 20: Since 00A0 is not listed in annex I, but 00C0 is, the sequence of characters a\u00C0b\u00A0 consists of two preprocessing tokens; the first is an identifier made up of three nondigits. (note also the correction to the annex cited). Replace 6.8p4 by: In the definition of an object-like macro, either the replacement list shall be separated from the identifier by white space, or it shall begin with one of the 26 graphic characters in the basic character set other than ( _ or \ (and thus shall not begin with a universal- character-name).[122] =========================================== Public Comment Number PC-UK0028 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-03 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Normative change to existing feature retaining the original intent Committee Draft subsection: 5.2.4.1 Title: clarify translation limit for identifiers using UCNs. Detailed description: In 5.2.4.1, change the relevant translation limits to: - 63 significant initial characters in an internal identifier or a macro name (a universal-character-name shall count as one) - 31 significant initial characters in an external identifier (a univeral-character-name shall count as 4 if less than 0000FFFF, and 8 otherwise) or some other wording that reflects the Committee's intent if different. =========================================== Public Comment Number PC-UK0029 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-03 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: [one of the following] Category: Normative change to existing feature retaining the original intent Committee Draft subsection: 5.2.4.2.2 Title: clarify rounding to nearest Detailed description: In 5.2.4.2.2p5, change the third case: 1 to nearest to: 1 to nearest (if the value to be rounded is exactly between two representable values, it is unspecified which is chosen) =========================================== Public Comment Number PC-UK0030 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-03 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Normative change to existing feature retaining the original intent Committee Draft subsection: 5.1.1.2 Title: Require UCNs to appear in translation phase 1 Detailed description: Currently, a source file can contain: \u12\ 34 and it is unclear whether or not this is a universal character name. Add to the end of 5.1.1.2 translation phase 2: If a character sequence that matches the syntax of a universal- character-name is produced by such splicing, the behavior is undefined. It is also unclear whether: ??/u1234 is a universal character name or not. I think the current wording allows it, but a footnote would be a good idea. =========================================== Public Comment Number PC-UK0031 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-03 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Normative change to existing feature retaining the original intent Committee Draft subsection: 7.3.1.9, 7.18.2.1.9 Title: make ispunct() true for basic punctuation characters Detailed description: There appears to be no character for which it is required that ispunct() is true. This is surprising, to say the least, as one would expect that it is true for characters like '.' and '('. Replace 7.3.1.9p2 by EITHER: The /ispunct/ function tests for any printing character for which neither /isspace/ nor /isalnum/ is true. OR: The /ispunct/ function tests for any character that is one of the 29 graphic characters in the basic execution character set or is one of a locale-specific set of printing characters for which neither /isspace/ nor /isalnum/ is true. In the "C" locale it returns true only for the characters in the basic execution character set. [These two are not equivalent outside the "C" locale.] =========================================== Public Comment Number PC-UK0032 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-04 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Inconsistency Committee Draft subsection: 6.1.2.1 Title: tidy-up specification of overlapping scopes Detailed description: The use of "non-overlapping" in 6.1.2.1p implies that the "scope" of an identifier excludes any block where the identifier is redeclared. This is inconsistent with the description of inner and outer scopes in paragraph 3; the latter is probably preferable. Change the word "non-overlapping" in paragraph 1 to "different". =========================================== Public Comment Number PC-UK0033 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-13 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.3.2.2 Title: Fix wording relating to "number of arguments" Detailed description: 6.3.2.2p2 states "the number of arguments shall agree with the number of parameters". This does not clearly take account of varargs functions. Change the wording to: the number of arguments shall equal or, if the prototype ends with an ellipsis (, ...), shall be no less than, the number of parameters (excluding any ellipsis). =========================================== Public Comment Number PC-UK0034 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-13 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.3.2.3 Title: Adjust wording concerning qualifiers on structure members Detailed description: 6.3.2.3p3 reads, in part: If the first expression has qualified type, the result has the so-qualified version of the type of the designated member. This should read: The result has all the qualifiers of the first expression and those of the designated member. Also add an example: In: struct s { int i; const int ci; }; struct s s; const struct s cs; volatile struct s vs; the various members have the types: s.i int s.ci const int cs.i const int cs.ci const int vs.i volatile int vs.ci volatile const int =========================================== Public Comment Number PC-UK0035 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-13 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Normative change to intent of existing feature Committee Draft subsection: 6.3.2.4, 6.3.3.1 Title: Allow increment/decrement of complex objects. Detailed description: All the operators that can be applied to a real floating object can also be applied to complex ones, with the sole exception of ++ and --. There is no obvious reason for this exception (particularly since the ! operator can be applied). In 6.3.2.4p1 and 6.3.3.1p1, change "real" to "arithmetic". =========================================== Public Comment Number PC-UK0036 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-13 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Normative change where the intent is unclear Committee Draft subsection: 6.3.16 Title: Define the result of the assignment operator Detailed description: 6.3.16p3 states: An assignment expression has the value of the left operand after the assignment, but is not an lvalue. It is not clear what this means when the left operand is a volatile object that changes through external causes - it could mean the value stored, or it could mean the result of reading the object. Replace these words with the unambiguous: The value of the assignment expression is the value stored in the left operand, but is not an lvalue. =========================================== Public Comment Number PC-UK0037 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-17 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Inconsistency Committee Draft subsection: 6.4 Title: Constant expression cannot contain the size of a VLA Detailed description: 6.4 does not require a constraint for "sizeof(v)" where v has variable length array type. FN83 also fails to notice this case. Append to 6.4p3: Any /sizeof/ operator shall have an operand whose size is defined to be constant. Move the reference to FN83 to the new end of the paragraph, and within the footnote change: not evaluated to: not evaluated when no component of the operand has variable length array type In 6.4p6 remove the words "sizeof expressions ... name of such a type". =========================================== Public Comment Number PC-UK0038 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-13 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Feature that should be removed Committee Draft subsection: 6.1.8 Title: UCNs should not be permitted in preprocessing numbers Detailed description: The syntax in 6.1.8p1 uses "nondigit", which used to represent the 52 letters plus underscore but now also includes the UCNs in Annex I. I believe this is a mistake, and the syntax should be adjusted accordingly. =========================================== Public Comment Number PC-UK0039 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-13 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Feature that should be included Committee Draft subsection: 6.1.3.1 Title: Allow 'i' suffix for floating constants Detailed description: It should be possible to write an imaginary floating point constant rather than having to multiply by the macro /I/. Furthermore, this macro is not available in a free-standing implementation. The obvious way to do this is to allow the suffix 'i' or 'I'. To do so: In 6.1.3.1p1: - Remove "floating-suffix/opt" from the various alternatives to "decimal-floating-constant" and "hexadecimal-floating-constant". - Append "floating-suffices/opt" to each alternative for "floating-constant". - Add: floating-suffices: floating-suffix imaginary-suffix imaginary-suffix floating-suffix imaginary-suffix: one of i I Append to 6.1.3.1p4: If the constant has the suffix /i/ or /I/, then its type and value are that resulting when the constant without that suffix is multiplied by the value of the macro /I/ defined in the header and add a forward reference to 7.8. =========================================== Public Comment Number PC-UK0040 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-13 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Normative change to intent of existing feature Committee Draft subsection: 6.5.2.1 Title: Bitfields of non-standard types should require a diagnostic. Detailed description: If a bitfield is declared with a type other than plain, signed, or unsigned int, the behavior is undefined. Since this can easily be determined at compile time, it should generate a diagnostic. An exception is required for the type underlying /bool/, and perhaps for any type that can have valid bitfields. Delete the first sentence of 6.5.2.1p8. Add to the end of 6.5.2.1p3: A bit-field shall have a type that is a qualified or unqualified version of /signed int/ or /unsigned int/, or of the type /bool/ defined in the header . or: A bit-field shall have a type that is a qualified or unqualified version of /signed int/ or /unsigned int/, of the type /bool/ defined in the header , or of some other implementation- defined integer type. =========================================== Public Comment Number PC-UK0041 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-13 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Inconsistency Committee Draft subsection: 6.5.2.2, 6.5.2.3 Title: An example uses an incomplete type in the wrong context Detailed description: 6.5.2.3 example 3 uses the line: enum f { c = sizeof (enum f) }; but 6.5.2.2p5 indicates that the type is not complete at the point it is used in the constant expression, and so a constraint is violated. The example must be reworded or deleted. =========================================== Public Comment Number PC-UK0042 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-13 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.5.4 Title: Clarify some aspects of inline Detailed description: In 6.5.4p6, add a footnote referenced at the end of the paragraph: [*] The call need not be due to the direct appearance of the name of the function at the point of calling; it may be through some kind of indirection. In 6.5.4p8, after: because /fahr/ is also declared with /extern/ add: (even though that declaration is not visible at the definition of /fahr/) =========================================== Public Comment Number PC-UK0044 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-14 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Inconsistency Committee Draft subsection: 6.5.7 Title: Removal of implicit int - further lacunae Detailed description: In 6.5.7p3, the last sentence: If the identifier is redeclared in an inner scope or is declared as a member of a structure or union in the same or an inner scope, the type specifiers shall not be omitted in the inner declaration. are no longer needed, as the type specifiers cannot be omitted. =========================================== Public Comment Number PC-UK0046 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-14 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.5.7 Title: Correct ranges of bitfields in an example Detailed description: In 6.5.7 example 3, change the specified ranges: - from "at least the range [-15, +15]" to "either the range [-15, +15] or the range [-16, 15]" - from "values in the range [0, 31] or values in at least the range [-15, +15]" to "values in one of the ranges [0, 31], [-15, +15], or [-16, +15]" =========================================== Public Comment Number PC-UK0047 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-14 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Request for information/clarification Committee Draft subsection: 6.8 Title: Handling of unknown preprocessing directives Detailed description: In the preprocessing phase (translation phase 4), consider the line: # unknown command It is unclear whether or not this requires a diagnostic. Presumably the # punctuator will remain until translation phase 7 where it cannot fit in the syntax, but even if so, this is less than clear. However, this is easy to fix. In the syntax in 6.8p1, change group-part to: group-part: non-directive new-line if-section control-line and add: non-directive: pp-tokens/opt Then add a constraints clause: Constraint The first preprocessing-token (if any) in a non-directive shall not be /#/. Finally, delete 6.8.3p8, because this can no longer occur. =========================================== Public Comment Number PC-UK0048 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-14 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. ? Category: Other: unresolved issue Committee Draft subsection: 6.1.7, 6.8.2 Title: Problems with UCNs in header file names Detailed description: Consider the line: #include "a$b.h" This will be changed, in translation phase 1, to: #include "a\u0024b.h" Both of these involve undefined behavior, but equally both are valid file names on at least one common operating system. It is likely that implementations that implement UCNs in a natural manner are going to have problems deciding which of the names was intended. I'm not clear what the answer is, but it needs addressing. =========================================== Public Comment Number PC-UK0049 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-14 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Request for information/clarification Committee Draft subsection: 6.8.1 Title: Handling of UCNs in character constants in #if directives Detailed description: Consider the line: #if '\u0024' < 100 where dollar is in the single-byte execution character set. It is not completely clear from 6.8.1p3 that the UCN is converted to a single character, since this normally happens in translation phase 5. In 6.8.1p3, last two lines of page 157 (postscript version), change: ... which may involve converting escape sequences into execution character set members. Whether ... to: ... which may involve converting source character set members, escape sequences, and universal character names into execution character set members in the manner of translation phase 5. However, whether ... =========================================== Public Comment Number PC-UK0050 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-14 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Inconsistency Committee Draft subsection: 6.1.2.8.1, 6.3.2.3 Title: Effects on other members of assigning to a union member Detailed description: 6.3.2.3p5 has wording concerning the storing of values into a union member: With one exception, if the value of a member of a union object is used when the most recent store to the object was to a different member, the behavior is implementation-defined. The requirement to be implementation-defined means that an implementation must ensure that all stored values are not trap representations in the types of other members, and thus, in effect, eliminates the possibility of trap representations at all. It turns out that the wording of 6.1.2.8.1 is sufficient to explain the behavior in these circumstances, and the cited wording in 6.3.2.3 merely muddles the issue. It should be removed; the rest of the paragraph can stand alone. =========================================== Public Comment Number PC-UK0051 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-16 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Inconsistency Committee Draft subsection: 7.1.7 Title: true and false are not reserved identifiers Detailed description: 7.1.7p3 defines "true" and "false" as macros, which thus reserves them in accordance with the third bullet of 7.1.3. FN138 suggests that an implementation could use these names as enumeration constants, but they are not reserved in that context. That is: #include #undef true; complex long double true; is strictly conforming. Since the implementation in the footnote is a useful one (for the reasons given), 7.1.7 should reserve these names at file scope, either explicitly or by changing these two identifiers to be "const int" (though of course this would give them an address). =========================================== Public Comment Number PC-UK0052 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-16 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Feature that should be included Committee Draft subsection: 6.8.3 Title: Add a __VA_COUNT__ facility for varargs macros Detailed description: Unlike with function calls, it is trivial for an implementation to determine the number of arguments that match the ... in a varargs macro. There are a number of useful things that can be done with this (at the least, providing argument counts to varargs functions). Therefore this information should be made available to the macro expansion. In 6.8.3p5, change The identifier /__VA_ARGS__/ ... to: The identifiers /__VA_ARGS__/ and /__VA_COUNT__/ ... Append to 6.8.3.1p2: The identifier /__VA_COUNT__/ that occurs in the replacement list shall be treated as if it were a parameter; it is replaced by a single token which is the number of trailing arguments (as a decimal constant) that were merged to form the variable arguments. =========================================== Public Comment Number PC-UK0053 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-17 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Feature that should be included Committee Draft subsection: 7.4 Title: Require consistency if an implementation adds to Detailed description: 7.20.3 reserves all names such as int11_t and uint_least22_t. This allows implementations to define them in , but does not require these names to be handled consistently. Adding such a requirement would aid portability. This proposal does not require any types other than those already required by the header. [The following is a minimal change. If requested, I can rewrite the header to integrate the changes better.] Append to 7.4 as a new paragraph 5: For each typedef name listed as /optional/ and which can be defined as a type existing in the implementation, it is unspecified whether or not the type is defined, but if it is provided, so shall the corresponding limit and /fprintf/ macros (as with all the types in this header, the /fscanf/ macros are optional). Append to 7.4.1.1, 7.4.1.2, and 7.4.1.3 as a new paragraph 4: Any other typedef name of these two forms is an optional type. Append to 7.4.2 as a new paragraph 3: Any optional types shall have /MAX/ and, if signed, /MIN/ macros with the appropriate name and value as if explicitly included in the following subclauses. For example, if the type /uint14_t/ is provided, then the macro UINT14_MAX shall be provided with value exactly 16383. Append to 7.4.4p1: Any optional types shall have /fprintf/ and /fscanf/ macros with the appropriate name and value as if explicitly included in the following lists. For example, if the type /uint14_t/ is provided, then the macros /PRIo14/, /PRIu14/, /PRIx14/, /PRIX14/, /SCNo14/, /SCNu14/, and /SCNx14/ should be added to the lists below. =========================================== Public Comment Number PC-UK0054 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-17 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Other: C++ conflict avoidance Committee Draft subsection: 6.8.8 Title: Require that __cplusplus not be defined Detailed description: Add to 6.8.8 a new paragraph 5: The implementation shall not predefine the macro /__cplusplus/, nor shall it define this macro in any header defined in clause 7. =========================================== Public Comment Number PC-UK0055 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-19 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.8 Title: It should be explicitly possible to redefine I Detailed description: 7.8p3 should end: Not withstanding the provisions of subclause 7.1.3, it is permitted to undefine and redefine the macro I. This was clearly the intent. =========================================== Public Comment Number PC-UK0056 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-19 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Feature that should be included Committee Draft subsection: 7.1.6 Title: Add a symbol giving the maximum alignment Detailed description: [I eventually decided is the right place for this.] Add a new macro to : _ALIGNMENT_ALL which expands to an integer constant expression that has type /size_t/, the value of which is the least common multiple of the alignments of all object types.[*] [*] If /p/ has pointer to character type and is suitably aligned for some type /t/, then /(p + _ALIGNMENT_ALL)/ is also suitably aligned for the same type /t/, no matter what /t/ is. Possibly also add the macros: _ALIGNMENT_INTS _ALIGNMENT_FLOATS _ALIGNMENT_POINTERS which are the least common multiples of the alignments for integer types, for floating types, and for pointer types respectively. Other names could also be conceived of (_ALIGNMENT_STRUCTS, _ALIGNMENT_UNIONS, _ALIGNMENT_SCALARS, etc.). =========================================== Public Comment Number PC-UK0057 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-19 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Normative change to intent of existing feature Committee Draft subsection: 7.13.2, 7.13.3, 7.19.3.10, 7.19.7 Title: Better locale handling for wide oriented streams Detailed description: 7.13.2p6 associates an /mbstate_t/ object with each stream, and 7.13.3p11-13 state that this is used with the various wide-oriented functions. On the other hand, 7.19.7p3 places very strict restrictions on the use of such objects, restrictions that cannot be met through the functions provided in the Standard while allowing convenient use of wide formatted I/O. Furthermore, an /mbstate_t/ object is tied to a single locale based on the first time it is used. This means that a wide oriented stream is tied to the locale in use the first time it is read or written. This will be surprising to many users of the Standard. Therefore, at the very least these objects should be exempt from the restrictions of 7.19.7; the restrictions of 7.13 (for example, 7.13.2p5 bullet 2) are sufficient to prevent unreasonable behaviour. In addition, the locale of the object should be tied and not affected by the current locale. The most sensible way to do this is to use the locale in effect when the file is opened, but allow /fwide/ to override this. In 7.13.2p6, add after the first sentence: This object is not subject to the restrictions on direction of use and of locale that are given in subclause 7.19.7. All conversions using this object shall take place as if the /LC_CTYPE/ category setting of the current locale is the setting that was in effect when the orientation of the stream was set with the /fwide/ function or, if this has not been used, when the stream was opened with the /fopen/ or /freopen/ function. In 7.19.3.10, add a new paragraph after paragraph 2: If the stream is successfully made wide oriented, the /LC_CTYPE/ category that is used with the /mbstate_t/ object associated with the stream shall be set to that of the current locale. In 7.19.7p3, append: These restrictions do not apply to the /mbstate_t/ objects associated with streams. =========================================== Public Comment Number PC-UK0058 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-29 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Request for information/clarification Committee Draft subsection: 7.13.4.3 Title: Unclear how many times tmpfile() can be called. Detailed description: Nowhere does the Standard state how many times tmpfile() can be called, nor does it state that several successful calls will actually access different files ! Append to 7.13.4.3p2: The file will be different from any other existing file, including any opened by a previous successful call to the /tmpfile/ function. Add a new part to 7.13.4.3: Recommended practice It should be possible to open at least /TMP_MAX/ temporary files during the lifetime of the program, and no limit on the number simultaneously open other than this limit and any limit on the number of open streams (FOPEN_MAX). The limit of /TMP_MAX/ could be shared with calls to /tmpnam/. =========================================== Public Comment Number PC-UK0059 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-19 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Inconsistency Committee Draft subsection: 6.8 Title: Add a description of the start symbol to the preprocessing grammar Detailed description: There is (still) no clear description of the grammar that a preprocessing file needs to obey. That is, the grammar is there but its applicability is not given. Add a new paragraph to 6.8 just before paragraph 5: As discussed in 5.1.1.1, the unit of program text before preprocessing (at the start of translation phase 4) is a preprocessing file. As shown in the grammar above, this consists of a sequence of conditional inclusion blocks, other preprocessing directives, and other text. =========================================== Public Comment Number PC-UK0060 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-19 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Inconsistency Committee Draft subsection: 7.2 Title: Clarify multiple insertions of Detailed description: The rules for including are partly in 7.1.2 and partly unstated. They should be stated more clearly in 7.2. Add to the end of 7.2p1: The /assert/ macro is redefined according to the current state of /NDEBUG/ each time that // is included. =========================================== Public Comment Number PC-UK0061 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-19 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Normative change to intent of existing feature Committee Draft subsection: 7.2.1 Title: Explicitly allow assert on non-integer arguments Detailed description: A DR response stated that assert need not correctly handle arguments which are not of type int but can be compared with zero. At the very least, this forbids arguments which are unsigned int or long, let alone other scalar types. Since it is trivial to have the macro convert any scalar to truth value integer by prefixing it with the !! operator, this restriction should be removed. In 7.2.1.1p1, change "int expression" to "scalar expression", where the word "scalar" is in italics. Add to paragraph 2, either after the first sentence or at the end: The argument of the /assert/ macro is any expression with scalar type. =========================================== Public Comment Number PC-UK0062 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-19 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Feature that should be included Committee Draft subsection: 7.13.3, 7.13.5.4 Title: Provide a way to make the standard streams binary Detailed description: 7.13.3p7 states that the three standard streams are text. This makes it impossible to write programs like "cat" on systems where text and binary streams are not the same. There are a number of ways to provide this facility. Here is my prefered one: add a new paragraph to 7.13.5.4 before paragraph 3: If /filename/ is a null pointer, the /freopen/ function attempts to change the mode of the stream to that specified by /mode/, as if the name of the file currently associated with the stream had been used. It is implementation-defined which changes of mode (if any) are permitted and under what circumstances. =========================================== Public Comment Number PC-UK0063 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-29 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Feature that should be included Committee Draft subsection: 7.13.9 Title: Provide a way to compare fpos_t values. Detailed description: There is no way to determine whether two fpos_t values represent the same position in a file. Therefore, it is not possible to do operations such as the following: - open a file - move through it, looking for some mark - note the position using fgetpos() - rewind - move through it again to the same position, using calls to fgetpos() to determine where you are, rather than relying on having made exactly the same sequence of reads and seeks Add a new function to 7.13.9: 7.13.9.X The fcmppos function Synopsis #include struct fcmppos fcmppos (fpos_t* pos1, fpos_t* pos2, FILE *stream) Description The /fcmppos/ function compares the values pointed to by /pos1/ and /pos2/, which must both refer to the stream /stream/. If either of the first two arguments is a null pointer, the result of a call to the /fgetpos/ function on the stream is used instead. If the stream has been written to at any point before the later of the two positions, the behaviour is undefined. Returns The value returned is a structured type containing at least the following fields: int before; // Less than, equal to, or greater than zero according // to whether /*pos1/ is before, at the same location // as, or after /*pos2/ in the file. int mbstate; // Zero if and only if the two positions have the same // multibyte parsing status. It will also be necessary to add /struct fcmppos/ to the start of 7.13. =========================================== Public Comment Number PC-UK0064 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-19 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Request for information/clarification Committee Draft subsection: 7.13.8.1, 7.13.8.2 Title: Clarify the actions of fread and fwrite Detailed description: The exact behaviour of fread and fwrite are not well specified, particularly on text streams. In 7.13.8.1p2, add after the first sentence: For each object, /size/ calls are made to the /fgetc/ function and the results stored, in the order read, in an array of /unsigned char/ exactly overlaying the object. In 7.13.8.2p2, add after the first sentence: For each object, /size/ calls are made to the /fputc/ function, taking the values (in order) from an array of /unsigned char/ exactly overlaying the object. =========================================== Public Comment Number PC-UK0065 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-20 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Request for information/clarification Committee Draft subsection: various Title: What is the precision of floating point calculations ? Detailed description: DR 063 asked, for C89, what was the required precision of the results of the various floating point operators and functions. To date this has not been answered. I am not aware enough of the issues to be able to write a good answer myself, but references to IEC 559 and annex F are not a sufficient solution. =========================================== Public Comment Number PC-UK0066 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-20 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Inconsistency Committee Draft subsection: various Title: The term "access" is not well defined. Detailed description: The term "access" is not well defined. From context, it sometimes appears to mean "read the value", and sometimes "read or write the value". This ambiguity sometimes makes it hard to understand what is actually meant. There needs to be a definition in clause 3, and all uses of the term need to be checked for the read-only / read-write problem. Probably the best approach is to define it as "read or write", and to find and fix the places where "read" is meant. An example where "access" clearly means "read" is in 6.5.3.1p5: A reference to a value means either an access to or a modification of the value. So "access" presumably means read but not write. But if so, then 6.5.3p6: What constitutes an access to an object that has volatile-qualified type is implementation-defined. must also exclude writing. But that would mean that what constitutes a write to a volatile object is *not* implementation-defined, but rather undefined ! Since this is obviously not the intent, there is a clear contradiction that needs resolving. There are plenty of other instances; for example, 6.3p6: ... If a value is stored into an object ... the type of the lvalue becomes the effective type of the object for that access ... where writing is clearly meant to be included. However, the point is not to address these individual cases but rather make the whole Standard consistent. =========================================== Public Comment Number PC-UK0067 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-21 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Other: tidy up (technically normative) Committee Draft subsection: 7.14 Title: tidy up definitions of macros Detailed description: In 7.14p3, change: EXIT_SUCCESS which expand to integer expressions which ... to: EXIT_SUCCESS which expand to integer constant expressions which ... and change: MB_CUR_MAX which expands to a positive integer expression whose value ... never greater than /MB_LEN_MAX/. to: MB_CUR_MAX which expands to a positive integer expression whose type is /size_t/ and whose value ... never greater than /MB_LEN_MAX/. This is not a constant expression: it may change whenever the locale changes. =========================================== Public Comment Number PC-UK0068 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-21 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Other: rewording to show consistency Committee Draft subsection: 7.14.6.2 Title: Change the description of div() to show consistency Detailed description: Change the description of the div function (7.14.6.2) to: Description The /div/ function computes the quotient and remainder of the division of the numerator /numer/ by the denominator /denom/. Returns The /div/ function returns a structure of type /div_t/, comprising both the quotient and the remainder. The structure shall contain the following members, in either order: int quot; // quotient, equivalent to (numer / denom) int rem; // remainder, equivalent to (numer % denom) If either part of the result cannot be represented, the behavior is undefined.[*] [*] The function is equivalent to: div_t div (int numer, int denom) { return (div_t) { .quot = numer / denom, .rem = numer % denom }; } Alternatively, simply replace the entire description by the code in the suggested footnote. =========================================== Public Comment Number PC-UK0069 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-21 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Normative change to intent of existing feature Committee Draft subsection: Annex G Title: Reorganise annex G as two separate items Detailed description: Annex G currently gives a specification for IEC 559 compatible complex types *and* for imaginary types, all conflated. These are separate concepts which can each be useful. Annex G should be split into two separate parts. The first annex is "Imaginary Types" and is normative. It begins something like: This annex specifies imaginary types. An implementation shall either conform to all the requirements of this annex, and shall define the macro /_Imaginary_I/ in , or it shall not provide such types, shall not define the macro /_Imaginary_I/, and shall not define the keyword /imaginary/. It then includes all the imaginary type parts: G.2, G.3, G.4.1p1-3, G.4.2 (except for the words "and exceptions"), G.5p1, G.6. The second annex is "IEC 559 compatible complex arithmetic" and is normative. It is introduced with words like those in F.1, including: An implementation that defines __STD_IEC_559_COMPLEX__ conforms to the specification in this annex. It then includes G.4.1p4-7, G.4.2p2, G.5 except p1. =========================================== Public Comment Number PC-UK0070 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-21 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Feature that should be included Committee Draft subsection: 7.9 Title: Type-generic macros should be generally useful Detailed description: 7.9 introduces the concept of type-generic macros, but these are only available for a small range of mathematical functions. This facility should be made generally available so that they can be used for general programming. =========================================== Public Comment Number PC-UK0071 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-21 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Inconsistency Committee Draft subsection: 6.8.2 Title: Clarify included file process Detailed description: 6.8.2p3 ends: If this search is not supported, or if the search fails, the directive is reprocessed as if it read #include new-line with the identical contained sequence (including > characters, if any) from the original directive. The wording is technically incorrect, precisely because the original directive could contain angle brackets within the quotes whereas an h-char-sequence cannot. Better wording would be: If this search is not supported, or if the search fails, the directive is reprocessed as if it read #include new-line with the identical contained sequence from the original directive (if the q-char-sequence contains a > character, this is retained in the name searched for even though it could not appear in a true h-char-sequence). =========================================== Public Comment Number PC-UK0072 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-21 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Feature that should be included Committee Draft subsection: 7.11.1.1, 7.14.4 Title: _exit function Detailed description: As part of a working paper (N789), I suggested that C provide an _exit() function like that in POSIX, and signal handlers should be allowed to call this function. After further discussion, it would still appear that this function is useful and can be specified in a way that is completely conformant to POSIX. However, I have made some improvements to the wording in N789. Make the following changes: In 7.11.1.1 paragraph 5, change: or the signal handler calls any function in the standard library other than the /abort/ function or the /signal/ function to: or the signal handler calls any function in the standard library other than the /abort/ function, the /_exit/ function, or the /signal/ function Add a new subclause 7.14.4.4 within 7.14.4 (Communication with the environment), renumbering subsequent subclauses. 7.14.4.4 The _exit function Synopsis #include void _exit (int status); Description The /_exit/ function causes normal program termination to occur, and control to be returned to the host environment. No functions registered by the /atexit/ function or signal handlers registered by the /signal/ function are called. The /_exit/ function never returns to the caller. The status returned to the implementation is determined in the same manner as for the /exit/ function. It is implementation- defined whether open output streams are flushed, open streams closed, or temporary files removed. =========================================== Public Comment Number PC-UK0073 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-01-21 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Other: clarification Committee Draft subsection: 6.5.5 Title: clarify order of evaluation of expressions within full declarators Detailed description: 6.5.5p3 states: The end of a full declarator is a sequence point. However, a full declarator can contain several expressions that require evaluation, and no ordering is stated. For example: int n; /* ... */ int v [++n][++n]; It is not clear whether this is undefined behavior (two modifications to n), unspecified behavior (which expression is evaluated first), or has a defined order. Change the cited wording to: The end of a full declarator is a sequence point; the various expressions within a full declarator are evaluated using the same rules for expression ordering as if they were combined into a single expression using the + operator. =========================================== Public Comment Number PC-____ ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-02-09 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Normative change to existing feature retaining the original intent Committee Draft subsection: 6.2.2.3 Title: a pointer to an object should point to its first byte Detailed description: Add a requirement that a pointer to an object should point to its first byte when cast to a pointer to a character type. Without this requirement, functions such as memcpy() and fread() will not work as intended. In subclause 6.2.2.3 add a new paragraph after paragraph 7: If a pointer to an object is converted to a pointer to character type, the result points to the lowest addressed byte of that object. Successive increments of the result, up to the size of the original object, yield pointers to the remaining bytes of the object. =========================================== Public Comment Number PC-____ ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-02-09 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Inconsistency Committee Draft subsection: various Title: problems with UCNs Detailed description: Further examination of UCNs shows that they have many problems associated with them, and in particular produce very different behaviour than would occur with C89. The following example was presented in comp.std.c by Antoine Leca and is summarised by me: What is the effect of the following code: #include #define str(s) #s int main(void) { printf (" # of <%s> is <%s>\n", "$", str ("$")); return 0; } Since $ is not part of the basic character set, this is not strictly conforming. However, assume that the implementation has a representation for $. Then, under C9X the output is clearly: # of <$> is <"$"> Under C9X, the output is probably one of: # of <$> is <"\u0024"> or # of <$> is <"\$"> At Translation Phase 1, both $s will be converted to \u0024, and so the source will become: #include #define str(s) #s int main(void) { printf (" # of <%s> is <%s>\n", "\u0024", str ("\u0024")); return 0; } When the # operator is applied as part of the expansion of str, the \ is doubled, producing the line: printf (" # of <%s> is <%s>\n", "\u0024", "\"\\u0024\""); in accordance with 6.8.3.2p2. Now, when TP5 is reached one has to decide whether the UCN is recognised first, generating: printf (" # of <%s> is <%s>\n", "\u0024", "\"\$\""); and undefined behaviour because of the escape sequence \$ - though I would expect at least some implementations to generate: # of <$> is <"\$"> - or else the escape sequence \\ is recognised first, generating the output: # of <$> is <"\u0024"> Neither, however, is what the naive programmer would expect, and neither interpretation allows a non-basic character to remain in a string that has the # operator applied to it. Another serious issue with UCNs is that they do not mix well with systems such as ISO 2022. Consider a situation where redundant shift sequences appear within string literals in source files. In C89 these sequences will be retained throughout the translation process and will appear when the literal is output by the program. In C9X the characters in the literal will be converted to UCNs and the shift sequences lost; a new set of, possibly different, shift sequences has to be added during TP5. For some applications this is a Quiet Change from C89. =========================================== Public Comment Number PC-____ ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-02-19 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Inconsistency Committee Draft subsection: 5.1.2.2.1, 5.1.2.2.3 Title: Alternate forms of main() are not well-enough defined Detailed description: 5.1.2.2.1 permits main() to have other implementation-defined types. These types might not include a return type of int. 5.1.2.2.3p1 reads: A return from the initial call to the /main/ function is equivalent to calling the /exit/ function with the value returned by the /main/ function as its argument.[10] If the } that terminates the /main/ function is reached, the termination status returned to the host environment is unspecified. The first sentence is clearly nonsense if the return type of main() is not convertable to int. Change 5.1.2.2.3p1 to: If the return type of the /main/ function is a type compatible with /int/, then a return from the initial call to the /main/ function is equivalent to calling the /exit/ function with the value returned by the /main/ function as its argument.[10] If the } that terminates the /main/ function is reached, or the return type of the /main/ function is not a type compatible with /int/, the termination status returned to the host environment is unspecified. =========================================== Public Comment Number PC-UK0077 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-03-09 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Normative change to feature Committee Draft subsection: 6.1.2.4, 6.6.4.2, 6.6.6.1, 7.10.2.1 Title: Fix semantics of jumps in relation to VLAs NOTICE - this is a replacement for PC-UK0045, which is withdrawn. Detailed description: Consider the code: { int n = 1; label: int v [n]; /* ... */ if (n++ < 10) goto label; } The constraint on 6.6.6.1 does not forbid this jump, but the storage for v cannot be allocated on block entry as described in 6.1.2.4p3. Consider the code: { int n = 1; goto label; int v [n]; label: /* ... */ } This also does not violate the constraint, but the size of the array is never determined. Consider the code: int n; /* ... */ if (n > 0) goto label; { n = 1; label: int v [n]; /* ... */ } This is forbidden by 6.6.6.1, but its meaning is clear and sensible. The intent of the constraint in 6.6.6.1 is clearly to prevent a jump into a block from skipping a VLA declaration, but as can be seen it does not have this effect in practice. Similarly, the wording of 6.1.2.4p3 for VLAs is obviously an attempt to adapt the previous wording, but it does not have the right effect. Previous discussion within WG14 appeared to reach the conclusion that: - jumping into the scope of a VLA should violate a constraint; - jumping out of the scope of a VLA causes storage to no longer be reserved, even if the block containing the declaration has not been left; and these rules seem eminently practical. To do this: In 6.1.2.4p3, replace: Storage is guaranteed [...] execution of the block ends in any way. with: For objects that do not have a variable length array type, storage is guaranteed to be reserved for a new instance of such an object on each entry into the block with which it is associated; the object initially has indeterminate value. If an initialization is specified for the value stored in each object, it is performed each time the declaration is reached in the execution of the block; otherwise the value becomes indeterminate each time the declaration is reached. Storage for the object is no longer guaranteed to be reserved when execution of the block ends in any way. For objects that have a variable length array type, storage is guaranteed to be reserved for a new instance of such an object each time the declaration is reached in the execution of the program. The initial value is indeterminate. Storage for the object is no longer guaranteed to be reserved when execution of the program leaves the scope of the declaration [*]. [*] Leaving the innermost block containing the declaration, or jumping to a point in that block or an embedded block before the declaration, leaves the scope of the declaration. In 6.6.4.2p1, replace the first sentence with: The controlling expression of a /switch/ statement shall have integer type. If the /switch/ statement causes a jump to within the scope of an identifier with variably modified type, the entire /switch/ statement shall be within the scope of that identifier [*]. [*] That is, the declaration either preceeds the /switch/ statement, or it occurs after the last /case/ or /default/ label that is in the block containing the declaration and is associated with the /switch/. In 6.6.6.1p1, replace the second sentence with: A /goto/ statement shall not jump from outside the scope of an identifier with variably modified type to inside the scope of that identifier. In 7.10.2.1, change the last sentence of paragraph 2 from: If there has been no such invocation, or if the function containing the invocation of the /setjmp/ macro has terminated execution [192] in the interim, the behavior is undefined. to: If there has been no such invocation, or if the function containing the invocation of the /setjmp/ macro has terminated execution [192] in the interim, or if the invocation of the /setjmp/ macro was within the scope of an identifier with variably modified type and execution has left that scope in the interim, the behavior is undefined. =========================================== Public Comment Number PC-UK0078 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-02-25 Author: N.M Maclaren Author Affiliation: Self Postal Address: University of Cambridge, Computer Laboratory, New Museums Site, Pembroke Street, Cambridge CB3 3QG, United Kingdom E-mail Address: Telephone Number: +44 1223 334761 Fax Number: +44 1223 334679 Number of individual comments: 1 Comment 1. Category: Normative change to existing feature retaining the original intent Committee Draft subsection: 5.1.1.2, 5.2.1 Title: Universal character name handling Detailed description: A nasty little problem arises in code like the following: #define str(a) #a str("$") In phase 1, the second line is mapped to str("\u0024") or perhaps str("\U00000024"). In phase 4, this will be mapped to #"\u0024" and (by 6.8.3.2 The # operator paragraph 2) to "\"\\u0024\"". In phase 5, this will be mapped to the execution character set, but there is no explicit statement of the priority of mapping escape sequences and universal character names. So it is probably mapped to the sequence of characters: '"','\\','u','0','0','2','4','"','\0' but (if universal character names take priority) to '"','\$','"','\0' which leads to undefined behaviour. In either case, this is a quiet change from C89. There are quite a lot of similar ambiguities commented on elsewhere, that need some sort of resolution. The more that I think about it, the less that I think the problems with these can be solved by tweaking, so here is a radical solution that I believe maintains all the functionality and resolves the problem. It is based on the principle that universal character names have a similar purpose to trigraphs and therefore should be treated similarly. I think that the following changes are all that are NECESSARY, but some more cleaning up may be desirable. 5.1.1.2 Translation phases Phase 1 should be rewritten as: 1. Physical source file multibyte characters are mapped to the source character set (introducing new-line characters for end-of-line indicators) if necessary. Secondly, trigraph sequences are replaced by corresponding single-character internal representations. Thirdly, universal-character-names are replaced by the corresponding single-character internal representations. Phase 5 should be rewritten as: 5. Each source character set member and escape sequence in character constants and string literals is converted to a member of the execution character set. Footnote 6 should be rewritten as: 6. The process of handling extended characters is specified in terms of mapping to an single-character encoding that includes the union of the whole source character set and the characters specified by ISO/IEC 10646-1, and, in the case of character literals and strings, further mapping to the execution character set. In practical terms, however, any internal encoding may be used, so long as an actual character encountered in the input, and the same character expressed in the input as a universal-character-name (i.e., using the \U or \u notation), are handled equivalently. Constraint 2 could be deleted, as it is now unnecessary. 5.2.1 Character sets A new paragraph 6 should be added: 6. Source characters shall be encoded as if the source character set included the whole of ISO/IEC 10646 as single characters, using an unspecified mapping to integral values (except as specified above). =========================================== Public Comment Number PC-UK0079 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-02-25 Author: N.M Maclaren Author Affiliation: Self Postal Address: University of Cambridge, Computer Laboratory, New Museums Site, Pembroke Street, Cambridge CB3 3QG, United Kingdom E-mail Address: Telephone Number: +44 1223 334761 Fax Number: +44 1223 334679 Number of individual comments: 1 Comment 1. Category: Editorial change/non-normative contribution Committee Draft subsection: 5.1.1.2 Title: Source line splicing Detailed description: One of the obscurer traps in C89 is that trailing spaces in C programs are significant in precisely one context: following the '\' used to splice physical source lines in translation phase 2. This causes considerable trouble on systems that support fixed-format records, because the implementation can treat those spaces as part of the end-of-line indicator, but need not do so. Many implementors think that the standard mandates trailing spaces to be regarded as significant. I suggest adding the following: Recommended Practice While mapping the physical source file to the source character set during phase 1, an implementation should regard an end-of-line indicator as being a maximal sequence of horizontal white space terminated by a single end-of-record indicator including any associated vertical layout directives. E.g. on a system that uses the same I/O model as C, "A \t \n\fB\n\n\t \tC\n" should be mapped to "A\nB\n\n\t \tC\n". =========================================== Public Comment Number PC-UK0080 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-02-25 Author: N.M Maclaren Author Affiliation: Self Postal Address: University of Cambridge, Computer Laboratory, New Museums Site, Pembroke Street, Cambridge CB3 3QG, United Kingdom E-mail Address: Telephone Number: +44 1223 334761 Fax Number: +44 1223 334679 Number of individual comments: 1 Comment 1. Category: Normative change to existing feature retaining the original intent Committee Draft subsection: 5.1.1.2 Title: Universal character names and #include Detailed description: I am afraid that universal character names have introduced some incompatibilities with C89, as in directives like '#include "a$b.h"'. This was defined in C89, but becomes undefined in C9X (i.e. it maps to '#include "a\u0024b.h"'). This is a deceptive trap, and one that will cause serious problems on some systems, as "$" is a fairly common character in header names. An evil variant of this is '#include "\udefault\a$b.h"' on MS-DOS and derivative systems. This maps to "\udefault\a\u0024b.h", which is either handled as such or mapped to "?ult\a$b.h", where '?' is whatever '\udefa' is. The current wording implies that one or the other approach should be used, though I don't think that it actually forbids mapping back to "\udefault\a$b.h". Note that these are quiet changes. In C89, "$" can be used in a program as a normal character, subject ONLY to it being a member of the basic source (and, if necessary, the basic execution) character sets. In C9X, it has an implementation-defined value that need not be that of any character. I suggest adding the following to help with the header and pragma problems: Whether a universal character name or character not in the the basic source character set is interpreted during phase 4 in its universal character name form or as a single character is implementation-defined. Under this circumstance alone, an actual extended character encountered in the input, and the same extended character expressed in the input as a universal-character-name, need not be handled equivalently. Recommended practice An implementation should, when appropriate, interpret characters in their input form during phase 4. A good implementation will diagnose uses when this is not the case, or where there is potential ambiguity. =========================================== Public Comment Number PC-UK0081 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-02-25 Author: N.M Maclaren Author Affiliation: Self Postal Address: University of Cambridge, Computer Laboratory, New Museums Site, Pembroke Street, Cambridge CB3 3QG, United Kingdom E-mail Address: Telephone Number: +44 1223 334761 Fax Number: +44 1223 334679 Number of individual comments: 1 Comment 1. Category: Normative change to existing feature retaining the original intent Committee Draft subsection: 5.1.1.2, 6.1.3.4, 6.1.4, Annex B Title: Universal character names and character constants Detailed description: If both the basic source and basic execution character sets include "$" (which is implementation-defined in both C89 and C9X), the following is true in C89: #include #if '$' <= UCHAR_MAX But this is NOT required by the current wording of paragraphs 10 and 11 in C9X, which leaves this case implementation-defined even if both the basic source and basic execution character sets include '$'. This is because the '$' expands to '\u0024', and the wording in those sections makes it quite clear that '\u0024' is neither a single character nor an escape sequence. Note that this affects ONLY translation phase 4, because phase 5 deals with the problem. I suggest moving "universal-character-name" in the Syntax section of 6.1.3.4 Character constants from being an entry in "c-char" to being one in "escape-sequence". This also needs to be done in 6.1.4 String literals and both places in Annex B, of course, but I can't see that it introduces any problems in any of them or other sections. =========================================== Public Comment Number PC-UK0082 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-02-25 Author: N.M Maclaren Author Affiliation: Self Postal Address: University of Cambridge, Computer Laboratory, New Museums Site, Pembroke Street, Cambridge CB3 3QG, United Kingdom E-mail Address: Telephone Number: +44 1223 334761 Fax Number: +44 1223 334679 Number of individual comments: 1 Comment 1. Category: Normative change to existing feature retaining the original intent Committee Draft subsection: 5.2.1 Title: Source character set values Detailed description: While investigating universal character names, I have realised that there does not seem to be any requirement on the characters in the source character set to have positive values, or even to be non-zero! 6.8.1 Conditional inclusion paragraph 3 adds a little implementation-definition, but not much. I suggest replacing the following sentence in paragraph 3: In both the source and execution basic character sets, the value of each character after 0 in the above list of decimal digits shall be one greater than the value of the previous. by: In both the source and execution basic character sets, the value of each character in the above list shall be strictly positive, the value of zero shall not correspond to any printing character, and the value of each character after 0 in the above list of decimal digits shall be one greater than the value of the previous. =========================================== Public Comment Number PC-UK0083 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-02-25 Author: N.M Maclaren Author Affiliation: Self Postal Address: University of Cambridge, Computer Laboratory, New Museums Site, Pembroke Street, Cambridge CB3 3QG, United Kingdom E-mail Address: Telephone Number: +44 1223 334761 Fax Number: +44 1223 334679 Number of individual comments: 1 Comment 1. Category: Inconsistency Committee Draft subsection: 5.2.1.2 Title: Multibyte characters and C89/C9X changes Detailed description: This appears to be a relic of C89, as far as the source character set is concerned, and is utterly baffling in the context of C9X. Here are some of the problems: 1) Paragraph 1 refers to multibyte characters in the source character set, but 5.1.1.2 bullet one refers to physical source file multibyte characters being mapped to members of the source character set. 2) The second bullet says that that the presence, meaning, and representation of any additional characters is locale-specific. But locale is an execution concept! I cannot find anything anywhere else in the standard that describes the concept of locale during compilation. 3) The fourth bullet says that a byte with all bits zero shall be interpreted as a null character, but the source character set is not required to include a null character (5.2.1. paragraph 2). 4) Paragraph 2 describes how multibyte characters must fit within various syntactic objects. But tokenisation does not occur until translation phase 3, and multibyte characters are mapped to universal character names in phase 1! 5) And, in any case, at what state should this be true? After phase 3, or after phase 4? Token concatenation and stringisation could cause trouble here, especially if a multibyte character in an identifier changed the shift state (ugh). I suggest replacing paragraph 1 by: 1. The source may be encoded using multibyte characters, used to represent members of the extended character set. The execution character set may also contain multibyte characters, which need not have the same encoding as for the source. For the execution character set, the following shall hold: Paragraph 2 should be replaced by: Recommended practice If the source is encoded using multibyte characters, a representation compatible with some conforming multibyte execution character set should be used. =========================================== Public Comment Number PC-UK0084 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-02-25 Author: N.M Maclaren Author Affiliation: Self Postal Address: University of Cambridge, Computer Laboratory, New Museums Site, Pembroke Street, Cambridge CB3 3QG, United Kingdom E-mail Address: Telephone Number: +44 1223 334761 Fax Number: +44 1223 334679 Number of individual comments: 1 Comment 1. Category: Request for information/clarification Committee Draft subsection: 6.1.2 Title: Identifier lengths Detailed description: Paragraph 6 is ambiguous. Do the 31 and 63 character limits include universal escapes as one character, or as their source length? This needs specifying clearly, one way or the other, or there will be serious confusion. I cannot suggest wording, as I do not know the committee's intentions. =========================================== Public Comment Number PC-UK0085 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-02-25 Author: N.M Maclaren Author Affiliation: Self Postal Address: University of Cambridge, Computer Laboratory, New Museums Site, Pembroke Street, Cambridge CB3 3QG, United Kingdom E-mail Address: Telephone Number: +44 1223 334761 Fax Number: +44 1223 334679 Number of individual comments: 1 Comment 1. Category: Feature that should be included Committee Draft subsection: 5.2.2, 6.1.3.4 Title: The escape character Detailed description: I still don't understand why '\e' isn't provided for ESC. The answer given in the C89 Rationale (that is is not available in EBCDIC) is quite simply wrong - evidence available upon request. It could clearly be added upwards compatibly but, equally clearly, its specification has to be that it does something implementation-defined (which is precisely what ASCII and ISO 646 say.) =========================================== Public Comment Number PC-UK0086 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-02-25 Author: N.M Maclaren Author Affiliation: Self Postal Address: University of Cambridge, Computer Laboratory, New Museums Site, Pembroke Street, Cambridge CB3 3QG, United Kingdom E-mail Address: Telephone Number: +44 1223 334761 Fax Number: +44 1223 334679 Number of individual comments: 1 Comment 1. Category: Request for information/clarification Committee Draft subsection: 6.8.1 Title: Invalid but skipped pre-processor directives Detailed description: Programs of the following form currently cause serious arguments, and I cannot see that the ambiguity has been resolved: #if 0 == 1 #axolotl #endif Is this permitted or is it not? I.e. is the undefined pre-processing directive "#axolotl" an error? Most compilers assume that it should be quietly ignored, but a few reject the above program fragment. Assuming that it should be ignored, I suggest a footnote in 6.8.1 Conditional inclusion after "the other preprocessing tokens in the group." along the lines of: 124a Thus unrecognised preprocessing directives in a group that is skipped are ignored and do not cause an error. Alternatively, if it should be an error, there should be some rewording to indicate that. =========================================== Public Comment Number PC-UK0087 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-02-25 Author: N.M Maclaren Author Affiliation: Self Postal Address: University of Cambridge, Computer Laboratory, New Museums Site, Pembroke Street, Cambridge CB3 3QG, United Kingdom E-mail Address: Telephone Number: +44 1223 334761 Fax Number: +44 1223 334679 Number of individual comments: 1 Comment 1. Category: Feature that should be included Committee Draft subsection: 7.4.4 Title: Macros for format specifiers Detailed description: These are all very well, but this is a major quiet change and not a welcome one, either. In C89, long is guaranteed to be the longest integer type, and it is possible to cast to long and use a simple format to print any integer. C9X abolishes this, and will break many programs. Even when they are rewritten, their formats will become unreadable. I suggest one of two solutions: 1) Restore the requirement that long is the longest integer type or: 2) Introduce %md, %mu, %mx etc. for the ***MAX forms to alleviate the pain, as has been suggested. This is still a change, but should cause less opposition. Doing BOTH enables programmers to convert their code to using intmax_t during the life of C9X, which leaves the option open for a future revision of the C standard to reintroduce 'long long' with minimum incompatibility, and is what I should prefer. The current proposal forces immediate and serious incompatibility, breaks existing and important conforming code, and makes it impossible to convert it cleanly to C9X. =========================================== Public Comment Number PC-UK0088 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-02-25 Author: N.M Maclaren Author Affiliation: Self Postal Address: University of Cambridge, Computer Laboratory, New Museums Site, Pembroke Street, Cambridge CB3 3QG, United Kingdom E-mail Address: Telephone Number: +44 1223 334761 Fax Number: +44 1223 334679 Number of individual comments: 1 Comment 1. Category: Normative change to existing feature retaining the original intent Committee Draft subsection: 7.13.8