Document Number: N807 J11/98-006 Title: CD1 public comments (US 001-006, UK 001-073) Date: 25 February 1998 ---------------------------------------------------------------------- UK Public Comments ---------------------------------------------------------------------- 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] Addendum -------- I have received a comment pointing out that "extended" is usually taken to include the set before extension; that is, the term could be taken to include the basic character set as well. An alternative term such as "supplementary" could be used instead. ---------------------------------------------------------------------- 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-UK0043 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: Clarify when VLA sizes are determined Detailed description: 6.5.7p3 reads in part: Any array size expression associated with variable length array declarators shall be evaluated with the typedef name at the beginning of its scope upon each normal entry to the block. This wording appears to say that VLA typedefs are evaluated when the block containing them is entered, even though this is not the case for any other kind of declaration (including VLAs themselves). For example: { int n; n = 5; int v1 [n]; n += 2; typedef int vec [n]; n += 2; vec v2; /* ... */ } The above wording would imply that vec, and so v2, contains either 5 or an undefined number of elements, rather than 7 that the average programmer would expect. Change the wording to: Any array size expression associated with variable length array declarators shall be evaluated with the typedef name at the beginning of its scope, and the resulting size shall be used whenever the typedef name is subsequently used. ---------------------------------------------------------------------- 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-UK0045 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: Normative change to feature Committee Draft subsection: 6.1.2.4, 6.6.4.2, 6.6.6.1 Title: Fix semantics of jumps in relation to VLAs 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 program; 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. If there is an initializer, it is performed at that point; otherwise 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. ---------------------------------------------------------------------- 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. ------------------------------------------------------------------------ USA Public Comments ------------------------------------------------------------------------ Public Comment Number PC-US0001 ------------------------------------------------------------------------ Date: 1998-01-21 (Received 1998-01-23) Author: David R. Tribble Author Affiliation: Self Postal Address: 6004 Cave River Dr. Plano, TX 75093-6951 USA E-mail Address: dtribble@technologist.com david.tribble@central.beasys.com dtribble@flash.net Telephone Number: +1 972 738 6125, 16:00-00:00 UTC +1 972 964 1729, 01:00-05:00 UTC Fax Number: +1 972 738 6111 ------------------------------------------------------------------------ Category: Request for clarification Committee Draft subsection: 6.1.1, 7.8 Title: 'complex' not always a keyword Detailed description: Section 6.1.1 states that 'complex' and 'imaginary' are reserved keywords only if the header has been included by the source program. In addition, the use of them prior to such an inclusion is deemed undefined. Why are they not treated as reserved words all of the time? One possible explanation is that this is an attempt to limit the number of existing programs that will break with the addition of new keywords. This, however, seems to be a moot point since the use of either keyword (without the inclusion of ) results in undefined behavior. Also, this is a weak argument in light of the fact that other new keywords have been introduced into the language (e.g., 'restrict' and 'inline') which could break existing programs. Another possible explanation might be that this is to preserve compatibility with C++, since C++ uses 'complex' as a template class name in its standard library. A clarification of this matter seems to be in order. An alternative is to require that 'complex' and 'imaginary' are always reserved words, regardless of the inclusion of or not. ------------------------------------------------------------------------ Public Comment Number PC-US0002 ------------------------------------------------------------------------ Date: 1998-01-21 (Received 1998-01-23) Author: David R. Tribble Author Affiliation: Self Postal Address: 6004 Cave River Dr. Plano, TX 75093-6951 USA E-mail Address: dtribble@technologist.com david.tribble@central.beasys.com dtribble@flash.net Telephone Number: +1 972 738 6125, 16:00-00:00 UTC +1 972 964 1729, 01:00-05:00 UTC Fax Number: +1 972 738 6111 ------------------------------------------------------------------------ Category: Request for clarification Committee Draft subsection: 5.1.1.2, 5.2.1, 6.1.2 Title: Source characters not allowed as UCNs Detailed description: Section 5.1.1.2 states that UCN codes representing characters in the source character set are not allowed within the source text. For example, the following fragment is illegal: int func(int i) { return \u0030; // \u0030 is '0' } int bar(int \u006A) // \u006A is 'j' { return \u006A + 1; } But this fragment is legal: int foo(int \u00E1) // \u00E1 is 'a'+accent { return \u00E1 * 2; } There is little difference in these fragments. What is the reason for the limitation on valid UCN codes? Conceivably, a Unicode text editor might store all the characters in a file as UCN sequences for maximum portability. Allowing most characters to be written as UCNs but requiring a few characters to be written strictly as 7-bit ISO-646 characters seems like an artificial restriction. A C compiler implementation could choose to convert all source characters into 16-bit (or even 32-bit) codes internally, preferring to convert UCNs into single internal codes as they are read. Why should it be prevented from accepting every alphanumeric ISO-10646 character, instead of every alphanumeric character /except/ 'a'-'z' et al? ------------------------------------------------------------------------ Public Comment Number PC-US0003 ------------------------------------------------------------------------ Date: 1998-02-05 (Received 1998-02-06) Author: David R. Tribble Author Affiliation: Self Postal Address: 6004 Cave River Dr. Plano, TX 75093-6951 USA E-mail Address: dtribble@technologist.com david.tribble@central.beasys.com dtribble@flash.net Telephone Number: +1 972 738 6125, 16:00-00:00 UTC +1 972 964 1729, 01:00-05:00 UTC Fax Number: +1 972 738 6111 ------------------------------------------------------------------------ Category: Normative change Committee Draft subsection: 4, 6.8.8, 7.1.3. Title: Useless __STDC__ macro Detailed description: Section 6.8.8 states that the predefined '__STDC__' macro has the value 1, indicating a conforming implementation. Section 4 states fairly clearly just exactly what a "conforming" and a "strictly conforming" implementation are. Section 7.1.3 states exactly what a "reserved" identifier is. While appealing in theory, the '__STDC__' macro is useless in practice. Programmers typically test for '__STDC__' in order to ascertain the answers to the following questions: 1. Does the implementation support the standard keywords and syntax (such as 'const', 'void *', and prototypes)? 2. Does the implementation supply the standard header files (such as and )? 3. Does the implementation supply the standard library functions (such as 'printf' and 'setjmp')? For example, the following fragment is typical for use with compilers that support a "compile in non-ISO K&R mode" switch, in order to allow for correct declarations in both ISO and K&R modes: #ifdef __STDC__ #define P(d) d #else #define P(d) () #endif extern int my_foo P((int arg)); extern void my_bar P((const char *n)); While conforming compilers are allowed to have extensions, some compilers deviate from 7.1.3 by providing keywords that reside in the unreserved namespace. For example, Microsoft Visual C provides the 'near' and 'far' keywords as extensions (for dealing with segmented pointer types on Intel hardware); as such, it is not conforming and so does not define '__STDC__' at all, even though it supports the full ISO C syntax and library. Other vendors, such as Sun, define '__STDC__' but define it to 0, presumably to indicate that they support the syntax and library of ISO C but still have extensions. Some vendors' compilers have a "ANSI/ISO compliance" switch that, when enabled, causes '__STDC__' to be defined as 1, but to cause all nonconforming constructs to be flagged as errors; this is fine in theory, but in practice it cripples a program, usually by disabling the declarations for system functions or by flagging such calls as errors. Unfortunately, 6.8.8 does not define what value '__STDC__' should have in such near-conforming implementations. Theoretically, the '__STDC_VERSION__' macro can be tested to determine what language features are supported. But there is no guarantee that this macro will be defined properly by vendors either. (Indeed, it isn't on many implementations.) Proposal: In order to clarify the issue, in the hopes of providing programmers a more useful macro, I propose that 6.8.8 be changed to the following: __STDC__ The decimal constant 1, indicating a fully conforming implementation, or the decimal constant 0, indicating a conforming implementation with extensions [note]. note: Such extensions would potentially cause some otherwise conforming programs to be nonconforming (such as the addition of keywords that are not reserved in this standard [7.1.3]). Implementations that are not conforming (with or without extensions) or that are incapable of translating strictly conforming programs shall not define this macro. (The very last "shall not" phrase might be considered a bit weak, because it attempts to define what nonconforming compilers cannot do. Such compilers, by their very nature, are not likely to abide by anything a standard has to say.) ------------------------------------------------------------------------ ------------------------------------------------------------------------ Public Comment Number PC-US0004 ------------------------------------------------------------------------ Date: 1998-02-09 Author: David R. Tribble Author Affiliation: Self Postal Address: 6004 Cave River Dr. Plano, TX 75093-6951 USA E-mail Address: dtribble@technologist.com david.tribble@central.beasys.com dtribble@flash.net Telephone Number: +1 972 738 6125, 16:00-00:00 UTC +1 972 964 1729, 01:00-05:00 UTC Fax Number: +1 972 738 6111 ------------------------------------------------------------------------ Category: Normative change to existing feature retaining the original intent Committee Draft subsection: 5.1.2.2.1. Title: Modifiable argv pointers Detailed description: Section 5.1.2.2.1 "Program startup" states that the 'argv' parameter to main() and the strings pointed to by the argv array shall be modifiable by the program. However, no mention is made of whether or not the pointers themselves shall be modifiable. It is my understanding that some systems allow the pointers to be modified without ill effects to the program, while other systems do not. Proposal: In order to clarify the issue, I propose that the following be appended to the last paragraph of [5.1.2.2.1 #2]: Whether or not the pointers of the argv array shall be modifiable by the program is implementation-defined. If they are modifiable, they shall retain their last-stored values between program startup and program termination. ------------------------------------------------------------------------ Public Comment Number PC-US0005 ------------------------------------------------------------------------ Date: 1998-02-10 (Received 1998-02-11) Author: David R. Tribble Author Affiliation: Self Postal Address: 6004 Cave River Dr. Plano, TX 75093-6951 USA E-mail Address: dtribble@technologist.com david.tribble@central.beasys.com dtribble@flash.net Telephone Number: +1 972 738 6125, 16:00-00:00 UTC +1 972 964 1729, 01:00-05:00 UTC Fax Number: +1 972 738 6111 ------------------------------------------------------------------------ Category: Normative change to existing feature retaining the original intent Committee Draft subsection: 7.1.6. Title: NULL macro type Detailed description: Section 7.1.6 [#3] states that the standard macro 'NULL' expands to an "implementation-defined null pointer constant". I feel that the standard ought to restrict the use of the 'NULL' macro to pointer expressions only, i.e., make it illegal to use 'NULL' as an integer expression. As defined currently, 'NULL' can be defined as '0' or '0L' as well as '((void*)0)'. The former two are integer constants, allowing for the possibility of 'NULL' being used as an integer constant on some implementations. Disallowing 'NULL' as an integer constant would make this dubious practice illegal. Proposal: I propose the following change to [7.1.6 #3]: [#3] The macros are NULL which expands to an implementation-defined null pointer constant of pointer type; and ... (The rest of the sentence is unchanged.) Discussion: [1] The use of 'NULL' as an integer constant is an inappropriate programming practice. Some examples are: int i = NULL; // Should be 0 char ch = NULL; // Should be '\0' or NUL memset(p, NULL, sz); // Should be '\0' or 0 if (ch > NULL) ... // Should be '\0' or 0 The 'NULL' macro ought to represent a pointer value, not simply a zero value. [2] Many implementations could define 'NULL' thus: #define NULL ((void*)0) which meets the requirements above. A few implementations use a representation other than "all bits zero" to represent a null pointer, so they could define 'NULL' as something like this: #define NULL ((void*)0x80000000) // ala IBM CICS The definition above does not restrict the type of 'NULL' to anything other than a pointer type; it is not required to be 'void*' per se, but could be whatever type the compiler vendor deems appropriate. For example: #define NULL __null // Vendor A #define NULL ((__notype*)0) // Vendor B In these cases, '__null' and '__notype' are implementation-specific reserved words with special meanings. (It is assumed that in both cases the type of 'NULL' is "implementation-specific pointer type".) ------------------------------------------------------------------------ Public Comment Number PC-US0006 ------------------------------------------------------------------------ Date: 1998-02-13 (Received 1998-02-13) Author: David R. Tribble Author Affiliation: Self Postal Address: 6004 Cave River Dr. Plano, TX 75093-6951 USA E-mail Address: dtribble@technologist.com david.tribble@central.beasys.com dtribble@flash.net Telephone Number: +1 972 738 6125, 16:00-00:00 UTC +1 972 964 1729, 01:00-05:00 UTC Fax Number: +1 972 738 6111 ------------------------------------------------------------------------ Category: Request for clarification Committee Draft subsection: 5.2.2, 7.3.1.4, 7.3.1.6, 7.3.1.8. Title: isprint('\t') Detailed description: Section 5.2.2 defines the semantics of the standard nongraphic characters ('\a' through '\v'). Sections 7.3.1.4, 7.3.1.6, and 7.3.1.8 define the iscntrl(), isgraph(), and isprint() library functions. What is not clear is whether the "nongraphic" characters of 5.2.2 are printable or not; in particular, is the result of isprint('\t') true or false? 5.2.2 states that '\t' et al are "nongraphic", which would seem to imply that isgraph('\t') is false, and by implication, isprint('\t') is also false. It is also unspecified whether or not the "nongraphic" characters are "control characters", i.e., it does not seem clear that iscntrl('\t') must be true. Vendors are inconsistent about this. (Unix vendors, for instance, usually define isprint('\t')==0, while Microsoft Visual C defines isprint('\t')!=0.) Most seem to agree that the "nongraphic" characters of 5.2.2 are control characters (so that iscntrl('\t') is true). But '\t' appears to be a special case; yes, it's a control character, but is it also a printable character (just like ' ')? This should be clarified in the standard. (I personally think that isprint('\t') should be false; after all, if it's true, shouldn't isprint('\f') and others also be true? But I think that would be a mistake.) Perhaps the use of the word "nongraphic character" (in 5.2.2) should be replaced with something more exact, such as "control character". And perhaps the definitions of the iscntrl(), isprint(), and isgraph() functions could be clarified so that it is impossible for some character code X to be both iscntrl(X)!=0 and isprint(X)!=0, i.e., the "control" and "printable" (or "graphic") characters are defined as mutually exclusive sets. (As I recall, Clive D. W. feather wrote something on this before, but apparently it didn't make it into the draft.) ------------------------------------------------------------------------