DOCUMENT WG14 N834 J11/98-033 This document contains the US Public comments on CD1 recieved from NCITS. No changes have been made to comment numbers or text. ------------------------------------------------------------------------------- Comment # Submitter Receipt Date Comment #1 David R. Tribble January 21, 1998 If the Technical Committee action is to accept in whole or in part a proposal contained in the comment, the changes should be sent to the Coordinator of Standards Processing together with any TC comments supporting the change. If the TC action is to reject in whole or in part = proposals contained in the comment, the response should provide the rationale for the rejection. The comment should be discussed at the next TC meeting, and if not definitively responded to at once, an interim acknowledgment should be sent along with an estimated date of action. The final response to the commenter must include the provision that the commentor has twenty working days from the postmark of the technical committees response to indicate, in a written statement, acceptance or rejection of the TC response. PUBLIC REVIEW COMMENT #1 Date: Wed, 21 Jan 1998 11:09:40 -0600 To: ddonovan@itic.nw.dc.us From: David R Tribble Subject: Comments on ISO/IEC 9899 (C9X) draft Public Comment Number(s) PC-____ to PC-____ ISO/IEC CD 9899 (SC22N2620) Public Comment Date: 1998-01-21 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 Number of individual comments: 2 ------------------------------------------------------------------------ Comment 1. 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. ------------------------------------------------------------------------ Comment 2. 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 REVIEW COMMENT #2 Date: Thu, 05 Feb 1998 20:31:32 -0600 To: ddonovan@itic.nw.dc.us From: David R Tribble Subject: Comments on ISO/IEC CD 9899 (C9X) Public Comment Number(s) PC-____ to PC-____ ISO/IEC CD 9899 (SC22N2620) Public Comment Date: 1998-02-05 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 Number of individual comments: 1 ------------------------------------------------------------------------ Comment 1. 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 REVIEW COMMENT #3 Date: Mon, 09 Feb 1998 12:22:57 -0600 To: ddonovan@itic.nw.dc.us From: David R Tribble Subject: Comments on ISO/IEC CD 9899 (C9X) Public Comment Number(s) PC-____ to PC-____ ISO/IEC CD 9899 (SC22N2620) Public Comment 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 Number of individual comments: 1 ------------------------------------------------------------------------ Comment 1. 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 REVIEW COMMENT #4 Date: Tue, 10 Feb 1998 21:00:46 -0600 To: ddonovan@itic.nw.dc.us From: David R Tribble Subject: Comments on ISO/IEC CD 9899 (C9X) Public Comment Number(s) PC-____ to PC-____ ISO/IEC CD 9899 (SC22N2620) Public Comment Date: 1998-02-10 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 Number of individual comments: 1 ------------------------------------------------------------------------ Comment 1. 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 =3D NULL; // Should be 0 char ch =3D 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 REVIEW COMMENT #5 Date: Fri, 13 Feb 1998 12:56:52 -0600 To: ddonovan@itic.nw.dc.us From: David R Tribble Subject: Comments on ISO/IEC CD 9899 (C9X) Public Comment Number(s) PC-____ to PC-____ ISO/IEC CD 9899 (SC22N2620) Public Comment Date: 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 Number of individual comments: 1 ------------------------------------------------------------------------ Comment 1. 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')=3D=3D0, while Microsoft Visual C defines isprint('\t')!=3D0.) 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)!=3D0 and isprint(X)!=3D0, 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.) PUBLIC REVIEW COMMENT #6 ISO/IEC CD 9899 (SC22N2620) Public Comment Date: 1998-2-24 Author: Andrew Josey Author Affiliation: The Open Group Postal Address: The Open Group Apex Plaza, Forbury Road Reading RG1 1AX United Kingdom E-mail Address: Telephone Number: +44 118 950 8311 Fax Number: +44 118 950 0110 Number of individual comments: 1 Comment 1. Category: Feature that should be included Committee Draft subsection: 7.16.3.6 Title: Century handling in strftime() Detailed description: (century handling in strftime) There is no century handling within strftime(). With the new century at hand this needs addressing . ISO C should include the %C conversion specification which has been in the X/Open Portability Guide since XPG4 (1992). After %c insert a new line %C is replaced by the century number (the year divided by 100 and truncated to an integer) as a decimal number [00-99] PUBLIC REVIEW COMMENT #7 ISO/IEC CD 9899 (SC22N2620) Public Comment Date: 1998-03-03 Author: Steve Summit Author Affiliation: individual Postal Address: 5812 15th Ave. NE Seattle, WA 98105 USA E-mail Address: scs@eskimo.com Telephone Number: +1 206 522 7534 Fax Number: n/a Number of individual comments: 97 ----------------------------------------------------------------- [begin boilerplate] Before I dive in with my comments, I have several apologies and disclaimers. I'm sorry that these comments are coming in at the last minute, and that there are so many of them. Most of them, at least, are editorial; I haven't made too many normative suggestions. My main goal is to help keep the revised document up to the high standards (for succinctness and accuracy) of its predecessor. I do not require feedback on any of these suggestions. I fully understand (without rancor) that many of them will not be used; the committee member(s) reviewing them need not feel guilty about abandoning them, and need not apologize to me for doing so. Where I have categorized a comment as "Request for information/ clarification", it is invariably a rhetorical question suggesting that the Draft's wording may need to be clarified; I am not requesting a personal response. I apologize, too, for the naivete which I'm sure some of these comments will display. I haven't kept up with the committee's work as much as I'd like, and some of the issues which I've expressed confusion about may well be straightforward. (On the other hand, I'm not completely uninformed about C, as I have been programming in it for about 20 years, maintaining the Usenet FAQ list on it for the past 10, and teaching it for the past 5.) Where I offer suggested new wording, I use two notations to suggest alternatives: words in square brackets [] are optional, and words between braces, separated by slashes (e.g. {this/that/the other}) are alternatives to be chosen among. I have scribbled more comments on my printout of the draft than I have had time to present here before the deadline. If any committee member is interested in, and somehow has time for, polishing the wording of the document, I would be happy to pass on more comments in the same vein (restricting them, of course, to editorial changes, non-normative contribution, and requests for clarification). [end boilerplate] I have divided my comments into three separate submissions. This one covers sections (clauses) 1 through 6. The second one covers section 7 and a few of the annexes, and the third one contains editorial comments and suggestions of a somewhat more nit-picky nature. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 1. Category: Request for information/clarification Committee Draft subsection: Introduction Title: "recommended practice" part of Standard? Detailed description: Are the "Recommended practice" subsections part of the Standard? By analogy with examples and footnotes, I suspect that they're not. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 2. Category: Inconsistency Committee Draft subsection: 1 / 5.2.4.1 Title: size/complexity constraints? Detailed description: Section 1 para. 2 bullet 5 says that the size and complexity are not constrained, but the translation limits in section 5.2.4.1 seem to provide exactly such constraints. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 3. Category: Editorial change/non-normative contribution Committee Draft subsection: 3 Title: typo #1 Detailed description: I think the word "by" is missing in front of the word "being". ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 4. Category: Editorial change/non-normative contribution Committee Draft subsection: 3.2 Title: "actual parameter" oxymoron Detailed description: I would *not* say that (actual) arguments are ever known as "actual parameter"; the word "parameter" strongly suggests "formal parameter". Moreover, the pair of words "actual parameter" appears nowhere outside of section 3.2. Please omit. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 5. Category: Editorial change/non-normative contribution Committee Draft subsection: 3.16 Title: "formal argument" oxymoron Detailed description: Similarly, "formal argument" strikes me as poor usage, and appears nowhere outside of section 3.16. Please omit. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 6. Category: Editorial change/non-normative contribution Committee Draft subsection: 3.18 Title: undefined behavior and diagnostics Detailed description: The wording at the end of para. 1 could be read o suggest that termination upon undefined behavior *does* require a diagnostic. I suggest changing the last "(with the issuance of a diagnostic message)" to "(with or without the issuance of a diagnostic message)". ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 7. Category: Request for information/clarification Committee Draft subsection: 5.1.1.1 Title: "linked" undefined Detailed description: The term "linked" appears in the last line of para. 1 and in several other places, with fairly significant implication, and although you and I know what it means, it is nowhere defined. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 8. Category: Editorial change/non-normative contribution Committee Draft subsection: 5.1.1.2 Title: misplaced constraint on universal-character-name Detailed description: The second sentence of para. 2 seems as if it belongs in section 5.2.1 para. 5. (I'm not sure I agree with the constraint, but I don't understand universal character names well enough to comment.) At any rate, the "Forward references" for 5.1.1.2 should probably include 5.2.1. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 9. Category: Editorial change/non-normative contribution Committee Draft subsection: 5.1.2.2.1 Title: argc/argv modifiability, part 1 Detailed description: I'd suggest removing the words "parameters argc and argv and the"; these parameters are obviously modifiable, as all parameters are. (See also Comment 10.) ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 10. Category: Request for information/clarification Committee Draft subsection: 5.1.2.2.1 Title: argc/argv modifiability, part 2 Detailed description: Is the array of pointers to char pointed to by argv modifiable? ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 11. Category: Normative change to existing feature retaining the original = intent Committee Draft subsection: 5.1.2.2.3 Title: exit / return from main equivalence Detailed description: I suggest moving the text of footnote 10 into the Standard. This is a frequently debated issue, and I'm not aware that footnote 10's statement is implied anywhere else in the Standard. (Indeed, section 5.1.2.2.3 para. 1 seems to suggest otherwise.) ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 12. Category: Request for information/clarification Committee Draft subsection: 5.2.1 Title: other characters in comments, etc. Detailed description: What is the behavior when "any other characters" are encountered *in* "a character constant, a string literal, a header name, a comment, or a preprocessing token that is never converted to a token"? Must they be allowed? I'd say it's implementation defined, but I think the Standard should say so. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 13. Category: Editorial change/non-normative contribution Committee Draft subsection: 5.2.1.1 Title: trigraph definition Detailed description: I'm not sure that word "corresponding" is obvious enough; I might be more explicit and say "each of the three-character sequences in the first column below is replaced with the corresponding single character from the second column." Also, this section may rate a forward reference to section 6.1.5; when at first I didn't find the digraphs here, I thought they'd been removed. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 14. Category: Request for information/clarification Committee Draft subsection: 5.2.1.2 Title: multibyte sequences/strings Detailed description: Although the term "multibyte character" is nicely defined, the terms "multibyte sequence" and "multibyte string" are introduced along the way (i.e. in later sections) as if we already know what they are, and their precise definitions are very hard to ferret out. It would be nice to collect them here (or perhaps in section 3.14). ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 15. Category: Request for information/clarification Committee Draft subsection: 5.2.1.2 Title: source multibyte characters Detailed description: Paragraph 2 seems to be constraining source files, not the source character set. (I'm not sure how to clarify this.) ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 16. Category: Normative change to intent of existing feature Committee Draft subsection: 5.2.4.1 Title: object limit of 32767 should be retained Detailed description: In the previous revision of this Standard, the limit on the size of an object was 32767. This allowed a 16-bit implementation to use a 16-bit signed type for ptrdiff_t. If an implementation must be able to handle at least one object of size 65536, and if this object is an array of char, ptrdiff_t must be (at least) a 17-bit type, meaning a 32-bit type in practice, leading to an unacceptable overhead on all *other* pointer differences. I feel that the translation limit of 32767 bytes on the size of one object should be retained. (I comment separately on section 7.4.5, with respect to the same issue.) ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 17. Category: Other: comment Committee Draft subsection: 5.2.4 Title: environmental limits scattered Detailed description: Several environmental limits appear elsewhere (specifically: in sections 7.13.2 para. 7, 7.13.3 para. 14, 7.13.4.4 para. 6, 7.13.6.1 para. 14, 7.14.2.1 para. 5, 7.14.4.2 para. 3, 7.19.2.1 para. 14), and this fact may be worth noting somewhere in section 5.2.4. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 18. Category: Other: comment Committee Draft subsection: 5.2.4.1 Title: some translation limits repeated Detailed description: A few of the translation limits in section 5.2.4.1 are repeated elsewhere (specifically: in sections 6.5.5 para. 7, 6.1.2 para. 6, 6.6.4.2 para. 4), redundantly. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 19. Category: Other: comment Committee Draft subsection: 5.2.4.2 Title: numerical limits scattered Detailed description: Several numerical limits appear elsewhere (specifically: in sections 7.4.2 and 7.4.5), and this fact may be worth noting in section 5.2.4.2. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 20. Category: Editorial change/non-normative contribution Committee Draft subsection: 5.2.4 Title: environmental limits scattered; some repeated Detailed description: In light of comments 17 to 19, para. 1 should probably say "...summarizes most of the environmental limits...". ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 21. Category: Request for information/clarification Committee Draft subsection: 6.1.2.2 Title: multiply-defined symbols Detailed description: Should paragraph 7 say "within a translation unit and a scope"? ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 22. Category: Request for information/clarification Committee Draft subsection: 6.1.2.4 Title: jumps into blocks containing "variably modified" objects Detailed description: In para. 3, in the sentence beginning "If the object is variably modified", it is not clear to me what "variably modified" means (or at least, it wasn't on first reading). Does this sentence describe the antithesis of the previous sentence, namely for objects that *do* have a variable length array type? If so, please use identical terminology. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 23. Category: Request for information/clarification Committee Draft subsection: 6.1.2.5 Title: better description of "rank", part 1 Detailed description: The word "rank" appears out of a clear sky in para. 7. It might be nice to introduce or motivate this term with a sentence like "For the purposes of describing the default conversions, each {arithmetic/integer} type is assigned a rank." It might also be nice, perhaps in a footnote, to provide a few words or an example connecting this new concept of rank back to the more familiar wording used in K&R or the previous Standard. (I see that sec. 6.1.2.5 forward references sec. 6.2.1.1; perhaps that suffices.) ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 24. Category: Normative change to existing feature retaining the original = intent Committee Draft subsection: 6.1.2.5 Title: type and representation of `complex' Detailed description: With respect to para. 12, a complex type presumably also has the same representation and alignment restrictions as the obvious two-member struct, and this fact is probably worth explicitly noting (i.e. specifying/requiring). (I'm not sure if homogeneous structs are otherwise guaranteed to be equivalent to arrays, and the reader may not be, either. But presumably if this guarantee of equivalence to an array is considered useful, the analogous guarantee for structs would be, too.) ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 25. Category: Request for information/clarification Committee Draft subsection: 6.1.2.5 Title: optionally named members? Detailed description: Does the word "optionally" in the second and third bullets of para. 17 refer to unnamed bit-field members, or to something else? ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 26. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.1.2.6 Title: multiply defined symbols Detailed description: Presumably, incompatible declarations of the same object or function are undefined only if in different translation units. Otherwise, they require a diagnostic. (If the wording here is changed, change Annex K sec. K.2, also.) ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 27. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.1.2.8.1 Title: vague pronoun reference #1 Detailed description: The word "that" in the first sentence of para. 2 has a vague antecedent. I suggest replacing it with "a particular". ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 28. Category: Request for information/clarification Committee Draft subsection: 6.1.3.1 Title: floating-point constant overflow Detailed description: Perhaps I'm missing something, but it doesn't look as if para. 3 explains what happens if the the scaled value is *not* in the range of representable values for its type. (The question is particularly interesting since sec. 7.7 para. 4 makes explicit reference to compile-time overflow of a floating-point constant.) ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 29. Category: Feature (specification) that should be included Committee Draft subsection: 6.1.3.4 Title: character constant limit Detailed description: I'm surprised there's no limit on the length of a character constant, as there is for a string literal (see sec. 5.2.4.1 bullet 16, of course). I believe a reasonable limit on the length of a character constant would be 4. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 30. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.1.5 Title: operator pairing wrt translation phase Detailed description: The first sentence of para. 2 should include the words "after translation phase 4", as sec. 6.1.6 does. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 31. Category: Request for information/clarification Committee Draft subsection: 6.1.5 Title: "designator" Detailed description: The word "designator" appears out of a clear sky in para. 3. Grepping the rest of the document for this term reveals that "function designator" is probably meant. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 32. Category: Normative change to intent of existing feature Committee Draft subsection: 6.1.7 Title: undefined characters in header names Detailed description: I believe that the behavior if unusual characters appear in h-char-sequences and q-char-sequences should be implementation-defined, not undefined. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 33. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.1.9 Title: continued // comments Detailed description: The fact that \ continues // comments is arguably wrong, and the fact that the preexisting translation phases forced this interpretation was (to my mind) the strongest arguments against adopting them. Given the surprisingness of this result, I'd say it rates a footnote ("Since backslash continuation occurs in translation phase 2, and comments are parsed in translation phase 3, a \ effectively continues a // comment; that is, the \\ does not "protect" the \ from interpretation") as well as appearing in the examples. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 34. Category: Request for information/clarification Committee Draft subsection: 6.2.1.1 Title: better description of "rank", part 2 Detailed description: As mentioned in comment 23, it might be nice to have a footnote connecting this new concept of rank back to the more familiar wording used in K&R or the previous Standard. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 35. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.2.2.3 Title: compatibility of converted function pointer types Detailed description: I believe that para. 8 should end with "...not compatible with the type of the converted pointer, the behavior is undefined." The function being called is always compatible with the called function! I think it would also be possible (and perhaps beneficial) to delete the last sentence entirely; I believe that sec. 6.3.2.2 para. 8 says the same thing. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 36. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.2.2.3 Title: misc. wording #1 Detailed description: In footnote 55, the word "yields" could be replaced (for more clarity, I think) with "would yield". ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 37. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.2.2.3 Title: misc. wording #2 Detailed description: In footnote 56, the words "correctly aligned" either need to be in italics, or in quotes, or replaced with the words "of correct alignment". ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 38. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.3 Title: undefined expression wording Detailed description: Although I understand it perfectly well now, for the longest time the classic second sentence of para. 2 was almost completely opaque to me. I might offer this replacement: Furthermore, an object may not be accessed and modified unless the access is { to determine / part of the calculation of } the value to be stored. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 39. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.3 Title: evaluation order and syntax Detailed description: The words "Except as indicated by the syntax" can be very misleading. Many people believe that explicit parentheses, or "operator precedence", *do* define aspects of evaluation order which we know to be undefined. Changing the word "subexpressions" later in the paragraph to "operands" might help. (Unfortunately I can't immediately think of a more substantial clear rewrite.) ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 40. Category: Request for information/clarification Committee Draft subsection: 6.3 Title: "object having no declared type" Detailed description: Is an "object having no declared type" one derived from malloc()? (This paragraph is fascinating, by the way.) ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 41. Category: 6.3.1.1 Committee Draft subsection: Title: "unadorned" name? Detailed description: The word "unadorned" appears almost nowhere else in this document. Is its meaning sufficiently clear? (Just now, I'm not even sure I understand its intent.) ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 42. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.3.2.2 Title: semantics of function call semantics Detailed description: I commend the rewording over the 1989/1990 version, which was nearly impossible to read. However, the breaking up into paragraphs (which is otherwise a good idea), combined with the paragraph numbers, leads to a new parsing challenge. Paragraph 6 is continuing the case that began in para. 5, but this may not be obvious upon first reading. (When I first read para. 6 in isolation, I could not understand it *at* *all*.) If at all possible, I would remove the explicit paragraph number from what is now para. 6. Having learned that paragraphs 5 and 6 go together, we might then assume that paragraphs 7 and 8 go together, but we'd be stymied again! Paragraph 8 applies to both cases (the non-prototype case of paras. 5/6 and the prototyped case of para. 7). It would be nice to make this connection more clear as well. Also, the clause "or if the prototype ends with an ellipsis" in para. 6 seems redundant; it seems that para. 8 should cover (or be made to cover) this case, as well, i.e. by the definition of compatible type for function pointers (sections 6.1.2.6 and 6.5.5.3). ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 43. Category: Other (comment) Committee Draft subsection: 6.3.2.3 Title: -> definition Detailed description: Is there any reason not to define p->m as (*p).m? That seems tidiest. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 44. Category: Request for information/clarification Committee Draft subsection: 6.3.2.5 Title: confused about example 8 Detailed description: I'm missing the point of example 8. The only difference I can see between the two loops concerns the explicit braces, which I guess is the point, but I'm still not seeing the point, or what would be the same or different. The introductory paragraph talks not about blocks but only about within/without a function body, and the words "same sequence of values for the objects associated with their respective compound literals" are just meaningless. Shouldn't the example be contrived to show some *difference* between the two loops, i.e by having function f() inspect them very carefully, or try to modify them? Also, to avoid more confusion, the function in the following example 9 should probably have a different name. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 45. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.3.3.3 Title: mildly confusing sequencing of - and ~ Detailed description: The wording of paras. 3 and 4 is mildly awkward -- it sounds a bit as if the operation is performed, then the integer promotion is performed, then the result is obtained. (Inserting "first" before "performed" in both places would help.) ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 46. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.3.3.4 Title: misc. wording #3 Detailed description: In para. 4, the word "as" or a comma should be inserted between "size_t" and "defined". ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 47. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.3.6 Title: wording in example Detailed description: "know" should be "known". Also, it might read better in the subjunctive: "If array... were declared..., and pointer... were declared..., the results would be the same." ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 48. Category: Committee Draft subsection: Title: Normative change to intent of existing feature Detailed description: Is it really the intent that bits not quietly fall off the left edge when shifting signed values to the left, but rather that the behavior be undefined? This seems a major change with respect to the 1989/1990 version, although reviewing it, I see that it didn't mention the signed case explicitly at all. Unless there are viable architectures which are known to have problems with this case, I'd very much like to see the signed case well-defined as well. (Is the problem those pesky padding bits?) ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 49. Category: Other (comment) Committee Draft subsection: 6.3.8 Title: comparison of incomplete pointers Detailed description: Paragraph 2 bullet 3, para. 5 2nd sentence, and para. 5 last sentence combine to say that if p and q have type void *, the expression p >=3D q yields 1 if p =3D=3D q and is undefined if p !=3D q. (I presume this is the intent.) ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 50. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.3.9 Title: pointer equality testing Detailed description: The wording in para. 4 seems cumbersome. Why not at least shorten the third and fourth sentences to "Two pointers to function types compare equal if and only if: they are both null pointers or both point to the same function." ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 51. Category: Normative change to intent of existing feature Committee Draft subsection: 6.3.9 Title: floating point equality Detailed description: Does there need to be an explicit caveat about the limitations of testing for floating point equality? For example, I've heard it alleged that the fragment double a =3D b + c; if(a !=3D b + c) printf("impossible!") might in fact print "impossible", if the register used to hold the intermediate result of the second addition has more precision than the object used to store c. (Perhaps I'm wrong, or perhaps this issue is covered elsewhere.) ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 52. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.3.13, 6.3.14 Title: misleading wording concerning short-circuiting Detailed description: Since most operators do not guarantee left-to-right evaluation, the words "Unlike the bitwise binary & operator" in sec. 6.3.13 para. 4 are potentially misleading. (By singling out & for this comparison, the reader might assume that it's unique in this regard.) No harm is done by removing the clause, and the analogous one in sec. 6.3.14 para. 4. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 53. Category: Request for information/clarification Committee Draft subsection: 6.3.15 Title: conditional operator cases: exhaustive? Detailed description: Perhaps I'm nitpicking, but though I used to think that the cases describing the second and third operands were nicely complete, now I'm wondering if they cover the (admittedly degenerate) forms e?NULL:NULL and e?(void *)0:0 . ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 54. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.3.16.1 Title: char/int truncation Detailed description: The word "may" in example 1 is potentially misleading. I suggest something like "the int value... will be truncated (assuming sizeof(int) > sizeof(char))..." ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 55. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.3.16.2 Title: semantics of compound assignment semantics Detailed description: The semantics description is one notch too terse. I'd expand it to A compound assignment of the form E1 op=3D E2 is equivalent to the simple assignment expression E1 =3D E1 op (E2), except that the lvalue E1 is evaluated only once. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 56. Category: Request for information/clarification Committee Draft subsection: 6.4 Title: diagnostics on compile-time overflow Detailed description: The placement of para. 4 within the constraints section implies that compile-time overflow is not undefined, but requires a diagnostic. Is this in fact the case? ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 57. Category: Request for information/clarification Committee Draft subsection: 6.5 Title: declaration constraints Detailed description: That word "excluding" in the parenthetical in para. 2 is a stumper. What, exactly, does it mean? As worded, it seems like it might be trying to say "above and beyond". It might be clearer (if I even understand what it's trying to say) to reword the parenthetical to "With the exception of function parameters and members of structures or unions,", and place it at the front of the sentence. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 58. Category: Request for information/clarification Committee Draft subsection: 6.5 Title: declaration constraints Detailed description: To the bullet list in para. 5, is there anything to be added about tags? (See e.g. sec. 6.5.2.3 paras. 1, 5.) ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 59. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.5 Title: declaration semantics Detailed description: I'd find para. 6 easier to read if "have" were changed to "specify". ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 60. Category: Normative change to existing feature retaining the original = intent Committee Draft subsection: 6.5.2 Title: complex declarations Detailed description: Shouldn't the keyword `complex' be able to appear alone, defaulting to double complex? (Since keywords like `signed' and `unsigned' can still appear alone, even though other instances of default int are being weeded out, it seems harsh to disallow plain complex.) ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 61. Category: Normative change to existing feature retaining the original = intent Committee Draft subsection: 6.5.2.3 Title: tag type completion Detailed description: Presumably the type is *incomplete* (para. 3) until the closing brace, and complete thereafter. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 62. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.5.3 Title: type qualifier examples Detailed description: Examples should not be in the running text of the Standard; the sentence beginning "For example," in the middle of para. 7 should be moved or removed. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 63. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.5.3 Title: another qualified pointer example Detailed description: I propose adding a third example, concerning an obscure but not uncommon situation: The function call in the fragment extern f(const char **q); char *p; f(&p); violates a constraint (see section 6.3.16.1) and requires a diagnostic. The call (or any assignment of char ** to const char **) is unsafe, because if function f were to perform the (valid) assignment *q =3D &c; where c was a const object, a later assignment by the caller to *p (e.g. *p2 =3D 0) would in fact be an attempted assignment to c. This example is adapted from one in the book "C Programming FAQs" which was supplied by Tanmoy Bhattacharya. The example might go in section 6.3.16.1 instead, but it seems worth waiting until qualified pointers have been fully introduced. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 64. Category: Request for information/clarification Committee Draft subsection: 6.5.3.1 Title: clarification of `restrict' Detailed description: My understanding of `restrict' is far from complete, so these questions may be misguided. The last half of para. 4 did not seem (to me) to rule out the second and third undefineds in example 4. In para. 5, I'm not sure what "attention" means, and I'm not sure *where* the "visible identifiers" are visible. Where is "the exception" mentioned in example 4 stated? What is the antecedent of the pronoun "this" in "this permits"? *If* I'm understanding this section at all, I'd insert "(necessarily single)" before "array object" in para. 4, and change "an object" to "a (possibly hypothetical) object" in para. 5. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 65. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.5.3.1 Title: `restrict' examples Detailed description: It might be worth noting that many examples of `restrict' can be found in section 7, e.g. in the declarations of functions such as sprintf, strcat, and memcpy. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 66. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.5.4 Title: `inline' examples and rationale Detailed description: The clause "by using, for example, an alternative to the usual function call mechanism known as `inline substitution'" should be moved into footnote 101 to keep examples out of the Standard. (Also, the modifier "known as" is ambiguously placed; apparently it is meant to attach to "an alternative" rather than "the usual function call mechanism".) It's too bad that this Standard will apparently not come with a Rationale document, as this section could really use one. What optimizations, really, are hinted/encouraged by `inline'? (Apparently not inlining across translation units.) Which optimizations must a compiler still perform entirely on its own, without hints? (Probably inlining across translation units.) If there are some compilers that will never perform inlining and some that are able to do it even without hints, what sorts of compilers are there in the middle, that will need the hints? [That's not a leading question; I honestly don't know the populations of any of the three categories.] I think I finally figured out that the sentence beginning "An inline definition does not provide..." in para. 6 is suggesting that it's okay to place inline function definition *in header files*, so that they will be available across translation units. An example demonstrating this would probably be helpful. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 67. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.5.4 Title: naked subclause references Detailed description: I think the word "section" or "subclause" is missing before "6.7" at the end of para. 8. (There are several examples of this omission throughout the Draft; I'll point out a few others that caught my eye. It's probably worth doing a global search for all of them, if there's an easy way.) ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 68. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.5.5 Title: inconsistent metaname Detailed description: In paragraph 5, the two italicized words should presumably be the same, both either "identifier" or "ident". ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 69. Category: Other (comment) Committee Draft subsection: 6.5.5.2 Title: restriction on variable-length types Detailed description: The two sentences in para. 2 seem to say the same thing. If they truly do, one can be removed; if there is some slight difference, it should probably be emphasized. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 70. Category: Request for information/clarification Committee Draft subsection: 6.5.5.3 Title: identifier lists in function declarators Detailed description: Paragraph 3 is tricky. After reading it several times, I finally realized that it is talking about identifier lists, *not* parameter type lists. So it is saying (of course) that these can only occur in function definitions, not external declarations; the declaration extern int f(a, b); is meaningless. But isn't it the case that some of the identifier lists in function definitions need to be empty as well? Consider int (*f(a, b))(c, d) { ... } The identifier list "c, d" is just as meaningless, and should probably be disallowed. (gcc correctly warns about these.) If paragraph 3 needs fixing in this regard, paragraph 10 probably does, too. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 71. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.5.7 Title: typedef examples Detailed description: In example 2, it should really say "pointed to by a value of type tp1" and "pointed to by a value of type tp2". (Also, should the last "and" be "or"?) In example 3, the construction "function returning signed int with one unnamed parameter with type pointer to function returning signed int with one unnamed parameter with type signed int" is impossible to parse. Changing the end of it to "and {having/accepting} one unnamed parameter with type signed int" would help. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 72. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.5.8 Title: the map is not the territory Detailed description: Paragraph 7 should end with "...the identifier shall name a member of that type." ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 73. Category: Inconsistency Committee Draft subsection: 6.5.2.1 / 6.5.8 Title: vacuous unions Detailed description: Section 6.5.8, para. 9 says that "A union object containing only unnamed members has indeterminate value even after initialization", but section 6.5.2.1 says that such a union is undefined. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 74. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.5.8 Title: default initialization order Detailed description: Paragraph 19 says "written in increasing subscript or member order", to which I would add "except as modified by any explicit designators." Paragraph 22 says "largest indexed element with an explicit initializer" which I would change to something like "element with the largest (explicitly or implicitly) indexed explicit initializer". ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 75. Category: Request for information/clarification Committee Draft subsection: 6.5.8 Title: redundant initializers Detailed description: Is it forbidden to use designators to initialize multiple elements of the same union? (For that matter, what happens if a structure member or array element is multiply, explicitly initialized?) Are the earlier initializers all "quietly overridden" by the later, as in the discussion of example 11? ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 76. Category: Other (comment) Committee Draft subsection: Title: 6.6.4.2, 6.6.6.1 Detailed description: Both sections prohibit jumping into blocks containing variably modified types, and both sections use the word "shall" in a constraint to do so. Therefore, a diagnostic is required. Will the diagnostic be straightforward for the compiler to generate? ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 77. Category: Request for information/clarification Committee Draft subsection: 6.6.6.1 Title: jumping past variably-modified declarations Detailed description: The wording in example 2 about "jumping past" a variably-modified declaration is just different enough from the Standard's wording that I'm suspicious that it says the same thing. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 78. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.6.6.4 Title: valueless return statements Detailed description: I don't think (what's left of) paragraph 4 is even necessary any more; now that valueless return statements in non-void functions are disallowed (i.e. by para. 1), the remaining undefined behavior is adequately covered by the requirements that the type of a called function match its definition. I was surprised, though, that the other sentence, from the 1989/1990 version, of what's now paragraph 4 was deleted. ("Reaching the } that terminates a function is equivalent to executing a return statement without an expression." I guess that statement couldn't remain, though, given the other changes.) ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 79. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.7.1 Title: typo #2 Detailed description: In para. 5, I believe the word "case" is missing between "in which" and "there shall not be an identifier". Also, since this clause is utterly significant, I don't think it should be a parenthetical. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 80. Category: Normative change to intent of existing feature Committee Draft subsection: 6.7.1 Title: old-style parameters shouldn't have to be declared Detailed description: The new requirement is imposed that "every identifier in the [old-style] identifier list shall be declared." This is a useless halfway stance between continuing to allow old-style definitions and banning them outright. Since old-style definitions do, in the general case, tend to omit explicit declarations for parameters of type int, many of them will need rewriting, but if the maintainers of old code are to be forced to revisit those old-style definitions, they will surely take the opportunity to update them completely to prototype style. I appreciate the fact that an attempt is being made to do away with default int, but the default should remain here. There is no point in forcing implementors to emit new diagnostics, and maintainers to rewrite new definitions, unless it's to go all the way and retire the old-style definitions. If they're to be retained at all, they might as well be retained in peace. (Although I suppose that those old-style definitions without explicit return types will need some revision, anyway.) ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 81. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.7.1 Title: redundant constraints on function compatibility Detailed description: Paragraph 8 seems redundant; functions without ellipses simply don't accept variable numbers of arguments, per language elsewhere. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 82. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.7.1 Title: timing of conversions during function calls Detailed description: Paragraph 10 says that array and function arguments "are converted to pointers before the call." This puts the horse behind the cart; it should say "have already been converted to pointers (per section 6.2.2.1)". ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 83. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.7.1 Title: parameter scope Detailed description: I think that the text of footnote 120 should be in the body of the Standard; I'm not aware of this specific point being made (explicitly or even implicitly) elsewhere. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 84. Category: Request for information/clarification Committee Draft subsection: 6.7.2 Title: default size of 1 for incomplete arrays? Detailed description: The assertion in example 2 that the array acquires a size of 1 took me by surprise. Is this fact implied by the words "with an initializer equal to 0" in para. 2, or what? ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 85. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.8.1 Title: semantics of #include semantics Detailed description: Since preprocessing arithmetic is essentially interpreted, without benefit of any declarations, I think that the first two instances of the word "types" in para. 3 should be replaced by "values". Also, the word "subclause" is missing before "6.4", and the antecedent of the pronoun "this" in "This includes interpreting..." is vague. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 86. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.8.2 Title: h vs. q char sequences Detailed description: Where paragraph 3 describes the fallback search, I think it should say ... reprocessed as if it read # include new-line (especially since it is explicitly specified that contained > characters are retained). ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 87. Category: Normative change to intent of existing feature Committee Draft subsection: 6.8.3 Title: empty variable-length macro argument lists Detailed description: This has certainly been thought about by more minds than mine, and there may well be issues I'm unaware of, but I'd say that the variable-length part of a variable-length macro argument list ought, just like those for functions, to be allowed to be empty. Therefore, I would change "more" in para. 4 to "at least as many", and I would add "(if any)" after "the trailing arguments" in para. 12. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 88. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.8.3 Title: misc. wording suggestions re preprocessor macros Detailed description: The word "declared" in para. 6 seems wrong; macro parameters are not formally declared. I'd just replace "uniquely declared" with "unique". It may be worth emphasizing (i.e. perhaps with a footnote) that the rescanning mentioned in para. 9 will be during replacement, *not* during definition! In paragraph 10, the function-like macro itself is *not* similar syntactically to a function *call*. I might replace "similar syntactically" with "which will be invoked with a syntax similar". The last sentence of para. 12 is hard to understand, until one realizes that "the number of arguments" following merger" counts "the variable arguments" as a single composite argument. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 89. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.8.3.3 Title: misc. wording #4 Detailed description: In para. 2, I'd add "of a function-like macro" after "in the replacement list". The large parenthetical in the middle of para. 3 is quite awkward; I'd make it a sentence in its own right, non-parenthesized. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 90. Category: Request for information/clarification Committee Draft subsection: 6.8.3.3 Title: restrictions on constructed tokens? Detailed description: Are there *any* restrictions on the tokens that can be constructed using ##, other than that universal character names are out? (If there are restrictions, it probably wouldn't be hard to state them in terms of translation phases, because that's where they'd arise.) "The resulting token is available for further macro replacement", but not as a macro parameter name, right? ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 91. Category: Inconsistency Committee Draft subsection: 6.8.3.3 Title: name of preprocessor concatenation operator Detailed description: The name "catenation operator" is used nowhere outside of the examples. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 92. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.8.3.4 Title: misc. wording #5 Detailed description: I would add the word "along" before "with all subsequent preprocessing tokens of the source file", and I would set the entire clause off with commas or by parenthesizing it. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 93. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.8.4 Title: line control syntax Detailed description: Shouldn't the syntax description in para. 4 should be # line digit-sequence "s-char-sequence" [opt] Or is the intent that an empty pair of quotes must remain if the s-char-sequence is omitted? If so, shouldn't it be specified whether the presumed source file name is set to null, or left unchanged, in this case? Also, could it be argued that #line should take a q-char-sequence rather than s? I would think that the arguments (e.g. possibly different treatment of \ in operating system filenames) which caused the concept of q-char-sequence to be introduced for #include would apply to #line as well. (If there's any substance to this speculation, the category I've given to this comment is wrong; it'd be a normative change.) ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 94. Category: Other (comment) Committee Draft subsection: Title: #error wrinkles Detailed description: Is it worth a footnote to point out that #error Hello, world! will work, and that #error "Hello, world!" may get you more quotes in the output than you'd expected? (Probably not.) I've always thought that it would be nice to be clearer on whether #error terminates translation, or perhaps to provide two variants (one which does and one which doesn't), but now is not the time to propose or discuss that. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 95. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.8.6 Title: #pragma musings Detailed description: I'd add "the compiler or" after "translation to fail or". I'm also puzzled why it's stipulated that macro replacement is *not* performed. By analogy with #include and #line, it seems that it should be, and it might even be useful. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 96. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.8.8 Title: predefined macro names (wording) Detailed description: It would be clearer if "and shall expand as indicated" were added after "shall be defined by the implementation." I'm not sure why the word "presumed" appears in __FILE__'s description, and not __LINE__'s. (Also, it might be worth explicitly noting that both of these are affected by #line). The parentheticals in the descriptions of __DATE__ and __TIME__ are significant enough that they should not be; I'd replace "source file (a character string" with "source file: a character string". Also, does the locale for the asctime function's creating of month names need to be specified? The word "shall" in para. 4 is odd. Presumably section 6.8.8 is complete, and all predefined macro names simply *do*, by observation, begin with two underscores. Is para. 4 trying to constrain implementation extensions, or state future directions? (In either case, the intent should be made clear.) ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 97. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.8.8 Title: typo #3 Detailed description: There's an obvious formatting problem in para. 2. PUBLIC REVIEW COMMENT #8 ISO/IEC CD 9899 (SC22N2620) Public Comment Date: 1998-03-03 Author: Steve Summit Author Affiliation: individual Postal Address: 5812 15th Ave. NE Seattle, WA 98105 USA E-mail Address: scs@eskimo.com Telephone Number: +1 206 522 7534 Fax Number: n/a Number of individual comments: 114 ----------------------------------------------------------------- [begin boilerplate] Before I dive in with my comments, I have several apologies and disclaimers. I'm sorry that these comments are coming in at the last minute, and that there are so many of them. Most of them, at least, are editorial; I haven't made too many normative suggestions. My main goal is to help keep the revised document up to the high standards (for succinctness and accuracy) of its predecessor. I do not require feedback on any of these suggestions. I fully understand (without rancor) that many of them will not be used; the committee member(s) reviewing them need not feel guilty about abandoning them, and need not apologize to me for doing so. Where I have categorized a comment as "Request for information/ clarification", it is invariably a rhetorical question suggesting that the Draft's wording may need to be clarified; I am not requesting a personal response. I apologize, too, for the naivete which I'm sure some of these comments will display. I haven't kept up with the committee's work as much as I'd like, and some of the issues which I've expressed confusion about may well be straightforward. (On the other hand, I'm not completely uninformed about C, as I have been programming in it for about 20 years, maintaining the Usenet FAQ list on it for the past 10, and teaching it for the past 5.) Where I offer suggested new wording, I use two notations to suggest alternatives: words in square brackets [] are optional, and words between braces, separated by slashes (e.g. {this/that/the other}) are alternatives to be chosen among. I have scribbled more comments on my printout of the draft than I have had time to present here before the deadline. If any committee member is interested in, and somehow has time for, polishing the wording of the document, I would be happy to pass on more comments in the same vein (restricting them, of course, to editorial changes, non-normative contribution, and requests for clarification). [end boilerplate] I have suggested that the descriptions of several library functions (e.g. fwprintf) be largely replaced with simpler descriptions in terms of another function (in fwprintf's case, of course, the basis function is fprintf). I have based my revised descriptions on mechanical, word-based diffs of the draft wording of the sections in question, and I would be happy to supply these listings (or the program that generated them) to any committee members who wish to verify that no non-accidental differences have been overlooked. I have divided my comments into three separate submissions. This one (the second) covers section 7 and a few of the annexes. The first one covers sections (clauses) 1 through 6, and the third one contains editorial comments and suggestions of a somewhat more nit-picky nature. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 1. Category: Request for information/clarification Committee Draft subsection: 7.1.1 Title: multibyte string definition Detailed description: "Shift sequence" is defined in paragraph 7 in terms of "multibyte string", but it's not obvious what a multibyte string is. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 2. Category: Request for information/clarification Committee Draft subsection: 7.1.2 Title: careful definitions of standard macros Detailed description: Paragraph 5 says that implementors must be careful with the definitions of standard object-like macros, but shouldn't the same thing be said about function-like macros? ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 3. Category: Normative change to intent of existing feature Committee Draft subsection: 7.1.3 Title: new reserved identifiers Detailed description: Would it be at all practical to arrange that identifiers with external linkage defined by this draft but *not* reserved by the 1989/1990 version, not be reserved unless their associated headers are included? Otherwise, there are quite a number of new "quiet changes." (As but one example, I suspect that many, many windowing libraries already define a function wprintf for formatted output into a window.) ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 4. Category: Request for information/clarification Committee Draft subsection: 7.1.3 Title: VPR #1 Detailed description: The reference to "that context" in para. 2 is exceedingly vague, and I'm not sure what is meant. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 5. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.1.4 Title: function definition of errno Detailed description: To avoid possible confusion, I recommend that the hypothetical function suggested by footnote 134 be named __errno, or _errno_function, or something. (Yes, I know, expansion of a particular macro isn't recursive, but still.) ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 6. Category: Other (comment) Committee Draft subsection: 7.1.6 Title: multiply defined standard typedefs Detailed description: Does an explicit statement need to be made (e.g. in a footnote) that "multiply defined" diagnostics for types such as size_t are guaranteed not to occur even if several different headers that define them are included? ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 7. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.1.8 Title: more global caveats Detailed description: I would add another general stipulation to the "Use of library functions" section, which although it is stated or implied elsewhere, seems well worth placing up front: When a function involves the copying of data, if the destination object or array is not big enough to hold the copied data, or if copying takes place between objects that overlap [*], the behavior is undefined. [* Footnote: since most library functions are not to be used to copy between overlapping regions, their pointer parameters are qualified with restrict.] (If placed here, the wording about "copying takes place between objects that overlap" can be removed from many individual function descriptions. It must be the case that they don't all need individual explicit statements, because not all of them have it now.) Also, to the parenthetical list of invalid values at the beginning of para. 1, I would add "or a pointer to a non-string". ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 8. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.2.1.1 Title: required information for assert's diagnostics Detailed description: The identifier __func__ has been added to the list in para. 2, making the words "the latter" wrong unless the words "the current function" are added somewhere before it. An example implementation would be nice, too. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 9. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.3.1.3 Title: typo #1 Detailed description: There's an extra "for" in the first sentence of para. 2. Also, the comma after "set of characters" is unnecessary, and the words "the following:" get in the way, and could be removed. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 10. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.3.1.7, 7.3.1.11 Title: misc. wording #1 Detailed description: Like section 7.3.1.2, sections 7.3.1.7 and 7.3.1.11 should reference footnote 146. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 11. Category: Other (comment) Committee Draft subsection: 7.3.2 Title: "corresponding" characters? Detailed description: Does the word "corresponding", as appearing in secs. 7.3.2.1 and 7.3.2.2, need any definition? ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 12. Category: Request for information/clarification Committee Draft subsection: 7.4 Title: "suitable character constants"? Detailed description: What are the "suitable character constants" defined by macros in , if not formatted I/O conversion specifiers? Was this meant to say "suitable integer constants", e.g. INTMAX_C? ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 13. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.4.5 Title: misdirected footnote? Detailed description: I doubt that para. 1 was meant to refer to footnote 151; footnote 150, perhaps. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 14. Category: Normative change to intent of existing feature Committee Draft subsection: Title: Detailed description: As I have said with respect to section 5.2.4.1, requiring all implementations to support 65536-byte objects has potentially serious effects on those with only 16 bits efficiently available. I recommend requiring only 32767 as the minimum maximum values of PTRDIFF_MIN, PTRDIFF_MAX, and SIZE_MAX. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 15. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.4.6 Title: typo #2 Detailed description: A comma is missing after the word "performed" in the second sentence of para. 1 in sec. 7.4.6.1, and in the same sentence cut-and-pasted into secs. 7.4.6.2-7.4.6.4. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 16. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.5 Title: typo #3 Detailed description: In para. 2, I believe it should say "*are* explained in [section/subclause] 7.5.2.1." ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 17. Category: Request for information/clarification Committee Draft subsection: 7.5.2.1 Title: localized characters or strings Detailed description: Since decimal_point, thousands_sep, et al. are described as being "characters", it might be nice to explain why they are declared as being multi-character strings. Is it so that they can be multibyte sequences? (Also, some descriptions, e.g. mon_decimal_point's, seem to be missing the word "character" or "string".) Are the members having to do with formatted monetary quantities, and which do not explicitly specify "internationally" or "locally", applicable to both, or just locally-formatted quantities? ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 18. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.5.2.1 Title: struct lconv: grouping and mon_grouping Detailed description: Paragraph 4 might rate a footnote pointing out that these are integer values, *not* characters, that you want 3 or '\3' (not '3') to specify a grouping of 3, and that the objects pointed to by grouping and mon_grouping are *not* necessarily null-terminated, nor are they in fact proper strings at all. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 19. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.6 Title: "the arithmetic" Detailed description: Two instances of "the arithmetic" in para. 1 read awkwardly, because we and this arithmetic haven't been properly introduced. I'd suggest replacing both with "floating-point arithmetic". ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 20. Category: Other (comment) Committee Draft subsection: 7.6.2.5 Title: misc. wording #2 Detailed description: I found the appearance of "bitwise OR" in the "Returns" clause (para. 3) momentarily confusing, because I'd think of the function as returning "the bitwise AND of the masks of currently set and queried exceptions". ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 21. Category: Other (comment) Committee Draft subsection: 7.6.3.2 Title: Detailed description: If it were like any of the other "set" functions in the standard library, fesetround would return not only a nonzero value, but the value of the previous mode. Would that be an option here? (I know nothing of IEC 559, so perhaps not.) Also, the description of the example refers to possible failure of the setting of the rounding direction, but there are two attempts to set; I'd say "...if setting the first rounding direction" or "if the first set of the rounding direction". ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 22. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.7 Title: weak xref Detailed description: "later" at the end of para. 1 is weak; why not say "in subclause 7.14.6" (if that's in fact where you had in mind)? ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 23. Category: Other (comment) Committee Draft subsection: 7.7 Title: compile-time floating constant overflow? Detailed description: With respect to para. 4: As I have commented elsewhere, section 6.1.3.1 does not say as much as it might about floating-point constant overflow. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 24. Category: Request for information/clarification Committee Draft subsection: 7.7 Title: Where is NAN? Detailed description: I can't find the description of the NAN macro. From reference to it in sec. 7.7.11.12 and elsewhere, I learn that it might be function-like, but I expected to see a formal statement to that effect somewhere, probably in a distinct subclause for the NAN macro. (If there is to be no such subclause, words could be added to para. 5.) ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 25. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.7 Title: Detailed description: I think the word "that" is missing in para. 7: "...indicates that the fma function...". Describing FP_FAST_FMAF and FP_FAST_FMAL as simply "analogs" is a little weak; if I wanted to be formal and pedantic I'd say they "describe, in the analogous way, { the behavior of / whether } the fmaf and fmal functions { are faster } than multiplies and adds of float and long double operands, respectively. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 26. Category: Other (comment) Committee Draft subsection: 7.7 Title: Detailed description: In para. 9, a sentence or footnote relating DECIMAL_DIG to FLT_DIG, DBL_DIG, and LDBL_DIG might be nice. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 27. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.7 Title: typo #4 Detailed description: There may be a formatting problem in footnote 171. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 28. Category: Request for information/clarification Committee Draft subsection: 7.7.4.3 Title: atan(inf)? Detailed description: Should there be any mention of the result of taking the arc tangent of an infinity, or are all such issues deferred to Annex F? (I see that sec. F.9.1.3 covers just the case I asked about.) ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 29. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.7.6.8 Title: one to the 177? Detailed description: The attachment of footnote 177 is *particularly* awkward -- can't it be placed somewhere else, e.g. after "function"? (Or was this a deliberate application of the teaching of Nicholas Vanserg, who advised that "The other side of the asterisk gambit is to use a superscript as a key to 14 a *real* footnote. The knowledge seeker reads that S is -36.7 calories and thinks `Gee what a whale of a lot of calories,' until he reads to the bottom of the page, finds footnote 14 and says, `oh.'"? ["Mathmanship", as reprinted in A Stress Analysis of a Strapless Evening Gown, Prentice-Hall, 1963, ISBN 0-12-852608-7]) ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 30. Category: Request for information/clarification Committee Draft subsection: 7.7.6.11 Title: partly perplexed by logb Detailed description: What does "in the format of x" mean? I would have had an easier time understanding this function if it were explicitly stated, up front, that the base with respect to which the exponent is extracted is FLT_RADIX. The second sentence is awkward; I might replace "normalized; thus for" with "normalized. For". ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 31. Category: Other (suggestion) Committee Draft subsection: 7.7.8 Title: erfc example? Detailed description: I don't have time to do the math or the implementation just now, but wouldn't a lovely example involving erfc be a function returning normally-distributed random numbers? ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 32. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.7.9.3, 7.7.9.4 Title: Detailed description: The description in sec. 7.7.9.3 involves a gratuitous forward reference. Why not interchange 7.7.9.3 and 7.7.9.4, and reword nearbyint's description to "The nearbyint function is { similar / equivalent } to the rint function, differing only in that..."? ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 33. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.7.9.6 Title: llrint: one more notch less equivalent Detailed description: To the description in para. 2, I would add: ", and the result is unspecified only if outside the range of long long." ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 34. Category: Other (comment) Committee Draft subsection: 7.7.9.7, 7.7.9.8 Title: Detailed description: I notice that lround's return value is long int, and that round's is not int but double. (There's a bit of invited confusion lurking here.) ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 35. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.7.9.9 Title: llround: one more notch less equivalent Detailed description: To the description in para. 2, I would add: ", and the result is unspecified only if outside the range of long long." ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 36. Category: Other (comment) Committee Draft subsection: 7.7.10.3 Title: remquo: what's it for? Detailed description: remquo's definition strikes me as being very strange. (Presumably there's some precedent in numerical work?) 3 seems woefully inadequate as the maximum guaranteed value for n; I'd have expected 10 or 15. Is the word "of" missing before "at least 3"? ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 37. Category: Other (comment) Committee Draft subsection: 7.8.2.24 Title: cexp example Detailed description: It occurs to me that it'd be cute to give an example showing that cexp(3.14159 * I) is pretty close to 1. (Or is it -1? It's been too long...) ----------------------------------------------------------------- ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 38. Category: Inconsistency Committee Draft subsection: 7.10 Title: setjmp: macro or not? Detailed description: Sec. 7.10 para. 3 says that it's unspecified whether setjmp is a macro, but sec. 7.10.1.1 refers to it (four times) as one. (Also 3 times in sec. 7.10.2.1 para. 4.) ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 39. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.12.1.2 Title: va_arg *not* guaranteed to have type of next argument Detailed description: The first sentence of para. 2 could be very misleading! I'd at least replace "argument" by "parameter", or perhaps replace "has the type and value of the next... in the call" with "fetches the value of the next argument in the call, which is {assumed/asserted} to have type _type_." ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 40. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.13.1 Title: what if I don't *want* any tmpnam's? Detailed description: The usage of "shall" with respect to TMP_MAX (in para. 3) is incorrect. "shall be generated" should be replaced by "shall be generatable" or simply "can be generated". ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 41. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.13.1 Title: I/O function classification Detailed description: The descriptions of the wide-character input and output functions claim they are described in "these subclauses", but of course they're described nowhere in 7.13, but rather in 7.19. The description of the byte input/output functions might say "functions described in these subclauses that perform bytewise input/output". ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 42. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.13.2 Title: internal vs. external representations Detailed description: Paragraph 2 might be more explicit in noting that it's only internal to the program that a text line consists of "zero or more characters plus a terminating new-line character". I'd add the words "internal to the program" (and perhaps even refer to the "abstract machine") somewhere in the first sentence, and add the word "external" before "host environment". ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 43. Category: Other (comment) Committee Draft subsection: 7.13.5.2 Title: misc. wording #3 Detailed description: Why is there a forward reference to 7.13.7.11? ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 44. Category: Normative change to intent of existing feature Committee Draft subsection: 7.13.5.3 Title: additional fopen modes Detailed description: I think that the behavior for mode strings other than those listed should be implementation-defined, not undefined. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 45. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.13.6.1 Title: fprintf description Detailed description: Paragraph 3 should be rewritten to use these sentences, adapted from 7.19.2.1, which are nice in and of themselves, and which must be moved here if my suggestion (see comment 95) to have 7.19.2.1 refer to 7.13.6 is adopted. The processing of conversion specifications is as if they were replaced in the format string by strings that are each the result of fetching zero or more subsequent arguments and converting them, if applicable, according to the corresponding conversion specifier. The expanded string is then written to the output stream. Section 7.9.2.1 uses present tense rather than 7.13.6.1's future perfect, and I think the former is preferable. I'd change each instance of "will be" to "is", "will begin" to "begins", "will have" to "has", and "will contain" to "contains". The subparagraph in sec. 7.13.6.2 para. 3 about size modifiers is somewhat nicer; if I had time, I'd try to fold some of it into 7.13.6.1. Also, I'd change two instances of "the argument will have been promoted... and its value shall be converted to" to "...but its value shall be converted back to". In the description of %g, I'd add "unless the # flag is specified" after "Trailing zeros are removed from the fractional portion of the result". With respect to paragraph 8, presumably a pointer to an array of integral type is as acceptable for %n as an array of char is for %s. Paragraph 14's wording is unnecessarily evocative of sec. 5.2.4's, and reads badly here. I'd simply say "An implementation shall be able to support at least 4096 characters as produced by any single conversion" or "If the number of characters produced by any one conversion exceeds 4096, the results are undefined." ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 46. Category: Inconsistency Committee Draft subsection: 7.13.6.1 Title: printf %hhn ? Detailed description: The description of %n in para. 6 mentions the possibility of %hhn, but the subparagraph about the n modifier in para. 3 does not. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 47. Category: Other (comment) Committee Draft subsection: 7.13.6.1 Title: printf format for complex Detailed description: Shouldn't there be a new printf (and scanf) format specifier for the new complex types? ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 48. Category: Other (comment) Committee Draft subsection: 7.13.6.1 Title: %a: any intellectual property problems? Detailed description: Using a formatted hexadecimal floating point representation is an idea I've had for a long time but have never found time to pursue; I'm delighted that the committee has introduced the %a formats. However, I was dismayed a few years ago to hear that IBM had somehow secured a patent on some variant of the same idea. Is there any chance that all implementors will end up owing IBM royalties for their (C9X-mandated) implementations of %a? ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 49. Category: Other (comment) Committee Draft subsection: Title: precision for %ls Detailed description: I suppose at one point it might have been an open question whether a precision specifier within %ls should count wide characters read from the source array or multibyte character bytes written to the output stream. Since much code is thinking more about the number of things being read from the array than the number of things being written to the stream, and since the count of bytes written ends up being so ambiguous (due to the possibility, though denied, of partial multibyte sequences), I'd say that it would have been better to specify the precision as counting source wide characters, but I suppose it's too late now. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 50. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.13.6.1 Title: fprintf examples Detailed description: The word "this" in para. 16 is misleading; at first I assumed it referred to the example I'd just read. It should either say "the next example", or the examples should be numbered (as they are in several other sections). I found the second example nearly impossible to understand for quite some time, until I realized that the notation "$0" was intended to refer to one byte. (Yes, para. 16 can and should be read to suggest otherwise, but I assumed that the $ was some kind of shift sequence. We are, after all, talking about multibyte sequences here.) I strongly suggest that a single character be used, either @ or some non-ASCII glyph. (If there was a taboo against using non-ASCII glyphs, the examples in sec. 7.13.6.2 have broken it.) ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 51. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.13.6.2 Title: fscanf wording Detailed description: Paragraph 3 is awkward; I'd add ", each of which is either: a sequence of" between "zero or more directives" and "one or more white-space characters". There's an extra "or" between l and ll in the first word of the third bullet item in para. 3. The singular/plural games in para. 6 are distracting. Is the reason for talking about characters plural being read from the stream that it might take several of them to match one (multibyte) character in the format string? The statement that a result is placed in "the object pointed to by the first argument following the format argument that has not already received a conversion result" is cumbersome and awkward, and seems as if it would be necessary only in the case of the numerically tagged specifiers which I've heard rumor that System V supports. Here, wouldn't it be easier just to talk about "the next argument"? (The description of fprintf seems to get by without any of this.) In the description of %f et al., "constant" should be changed to "number" and "string" should be changed to "sequence" (if for no other reason than that these are the words that sec. 7.19.2.2 uses). In the second subparagraph describing %[, a subparagraph break before "the conversion specifier includes" would help. In paragraph 14, the parenthetical should be changed to "(other than %n, if any)" (for consistency with fwscanf sec. 7.19.2.2). I don't find the first sentence of footnote 218 implied anywhere in the Standard; I'd like to see it moved there. Should the last sentence of the Returns section (para. 17) say "...in the event of early matching or input failure"? (If so, all of the descriptions of the *scanf and *wscanf functions are affected.) ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 52. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.13.6.2 Title: fscanf examples Detailed description: Shouldn't the first paragraph of the examples get a new paragraph number? The parallelism in the description of example 1 is quite poor; I'd replace "name will contain thompson\0" with "to the array name the string "thompson"". *Please* don't use feof in this Pascalish way in example 3! Either use fscanf's return value somehow (since it's being carefully saved, although currently not otherwise used), or retain feof/ferror, but in a do/while loop. The construction "the stdin stream contains" is awkward; I'd say "If the following lines are available on stdin". In (the awkwardly numbered) paragraph 18, "these" is again misleading, and should be replaced with "the following". Also, a one-character glyph such as @ or some non-ASCII character should again be used instead of $0. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 53. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.13.6.5 Title: sprintf wording Detailed description: The placement of the clause "rather than to a stream" in para. 2 is awkward; it seems to attach to "the argument s", not "an array". I'd reword it thus: ...except that the output is written to the string s, rather than to a stream. Also, I'd replace "returned sum" with "returned character count". ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 54. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.13.6.6 Title: snprintf Detailed description: Hooray! This was the single greatest gaping need in the old standard; I'm overjoyed to see it introduced here. I'd make the first change suggested in comment 53 here too, though. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 55. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.13.6.7 Title: sscanf wording Detailed description: I'd reword the first sentence in para. 2 to end with "...except that the input is read from the string s, rather than from a stream." ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 56. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.13.6.8 et al. Title: vfprintf wording Detailed description: I'd change "(and possibly subsequent va_arg calls)" to "(and possibly {modified/affected} by subsequent va_arg calls)". If you agree, the change should be made to all of the v*printf and v*scanf descriptions (including those in sec. 7.19.2). ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 57. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.13.6.10, 7.13.6.11 Title: typo $5 Detailed description: In these sections (and a large number of other sections), the sentence "If copying takes place between objects that overlap, the behavior is undefined" should probably be removed." It's true in more sections than it appears, but since it appears in so many of them, someone might get the impression that it *doesn't* apply where it doesn't appear. Rather than repeating it ad nauseum, it should be stated up front in section 7.1.8, with the restrict qualifiers in the individual function descriptions serving as a reminder. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 58. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.13.6.12, 7.13.6.13, 7.13.6.14 Title: typo #6 Detailed description: In each section, the word "function" is missing before "does not invoke the va_end macro". ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 59. Category: Normative change to intent of existing feature Committee Draft subsection: 7.13.7.2 Title: array contents after fgets error Detailed description: I'd say that "indeterminate" is too strong a statement on the undefinedness of the array contents after error. Realistically, each element of the array will either contain some character read before the error occurred, or some character that was there before fgets was called. There seems no chance of a read error causing the sorts of "taboo" bit patterns to occur that the term "indeterminate" tends to suggest. I'd say that the array contents after error ought to be defined as unspecified. (If by chance you agree, the same change should presumably be made to gets sec. 7.13.7.7, although anyone who call gets deserves whatever he gets.) ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 60. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.13.7.3 Title: fputc in append mode Detailed description: In para. 2, near the existing wording "at the position indicated by the associated file position indicator for the stream (if defined)", don't some words need to be added along the lines of "or at end-of-file if the stream was opened in "a" mode"? ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 61. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.13.8.1 Title: fread "elements" undefined Detailed description: The descriptions of both fread and fwrite refer to "elements" read or written, but this term (with this usage) is nowhere defined. Use of it only suggests that the functions might somehow treat array elements specially, e.g. by byte-swapping the elements of an array of int appropriately (though how the functions could ever know what swapping might be appropriate is of course indeterminable). Either the term "element" needs to be specifically defined as "an array of unsigned char of size size", or the descriptions need to be rewritten to use "bytes" instead of "elements". For example: The fread function reads, into the array pointed to by ptr, up to nmemb*size bytes from the stream pointed to by stream. The file position indicator for the stream (if defined) is advanced by the number of bytes successfully read. If an error occurs, the resulting value of the file position indicator for the stream is indeterminate. If the number of bytes successfully read is not a multiple of size, the value of the last block of size bytes is indeterminate. Returns The fread function returns the number of bytes successfully read, divided by size, which may be less than nmemb if a read error or end-of-file is encountered. If size or nmemb is zero, fread returns zero and the contents of the array and the state of the stream remain unchanged. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 62. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.13.8.2 Title: fwrite "elements" undefined Detailed description: See the discussion under comment 61. My suggested rewrite is The fwrite function writes, from the array pointed to by ptr, up to nmemb*size bytes to the stream pointed to by stream. The file position indicator for the stream (if defined) is advanced by the number of bytes successfully written. If an error occurs, the resulting value of the file position indicator for the stream is indeterminate. Returns The fwrite function returns the number of bytes successfully written, divided by size, which will be less than nmemb only if a write error is encountered. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 63. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.13.9.1 Title: fgetpos description Detailed description: The file position indicator is of course no longer the only information stored. I would change ...the current value of the file position indicator for the stream pointed to by stream in the object... to ...the current value of the file position indicator and the mbstate_t object for the stream pointed to by stream into the object... or simply ...information about the current state of the stream pointed to by stream, including the file position, indicator [and the mbstate_t object], into the object... ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 64. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.13.9.2 Title: fseek wording Detailed description: In para. 2, "If a read or write error occurs" should be replaced with "If an error occurs". In para. 5, some words could be added (analogous to those in 7.13.9.3 para. 3) about a change from reading to writing, or vice versa, now being possible for "r+", "w+", and "a+" streams. ----------------------------------------------------------------- Comment 65. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.13.9.3 Title: fsetpos wording Detailed description: In para. 2, "If a read or write error occurs" should be replaced with "If an error occurs". In para. 3, I'd add ", resets the mbstate_t object for the stream to that saved in *pos," before "and undoes any effects of the ungetc function on the same stream". ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 66. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.14.1.3, 7.14.1.4 Title: atol/atoll description discrepancy Detailed description: The descriptions (paras. 2) of atol and atoll are curiously different. Is there any intent? ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 67. Category: Request for information/clarification Committee Draft subsection: 7.14.1.5 Title: strtod description Detailed description: Do the words "but no floating suffix" in para. 3 apply to all the bullets above? I assume so, in which case I would replace the fragment with "In no case is a floating suffix expected or accepted in the subject sequence." ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 68. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.14.1.6, 7.14.1.7 Title: typo #7 Detailed description: In both descriptions, "expect" should be replaced by "except that". ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 69. Category: Request for information/clarification Committee Draft subsection: 7.14.1.7 Title: strtold precision Detailed description: Does the vague wording "similar to the strtod function" adequately imply the function's presumably superior ability to accurately reflect converted strings with large numbers of significant digits? ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 70. Category: Request for information/clarification Committee Draft subsection: 7.14.1.8 Title: strtol: null required? Detailed description: Paragraph 1 suggests that the final string includes the terminating null character; does this mean that char x[3] =3D "12x"; (void)strtol(x, NULL, 10); is undefined? ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 71. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.14.1.8 Title: strtol wording Detailed description: For consistency with wcstol, in para. 3, add "(inclusive)" after "base is between 2 and 36", change "10 to 35" to "10 through 35", and add "and digits" before "whose ascribed values are less". Also, add "subclause" before "6.1.3.2" in para. 5. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 72. Category: Feature that should be included Committee Draft subsection: 7.14.1.10 Title: strtoi Detailed description: Given that strtof has been added, I believe that strtoi should be, as well. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 73. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.14.1.10 Title: strtoul wording (too much of) Detailed description: Given that strtoul's description is nearly identical to strtol's, it could (and I think should) be replaced with The strtoul function is equivalent to the strtol function, except that the return value is type unsigned long int. That's really the *only* difference, other than the Returns section, which would be given separately and explicitly, anyway. My justification for the simplification is on general grounds of parsimony, and also to make it easier for a reader to verify that the two functions are, in fact, nearly identical. I happen to have access to this draft in electronic form and to a word-based diff program, but many readers will have neither. (As a matter of fact, I think there should be a second and more significant difference, namely that strtoul should not accept a minus sign, but I guess it's too late for that now.) If strtoul's text is not coalesced with strtol's, the exact same comments as given above in comments 70 and 71 apply. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 74. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.14.2.1 Title: rand recommended practice Detailed description: Given that other sections have broken the ice on "Recommended Practice" subsections, I would really love to see one for rand, encouraging implementors to use an implementation (such as the example in sec. 7.14.2.2) which allows users to take rand() % n with decent results. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 75. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.14.3 Title: malloc recommended practice Detailed description: It would be nice to see some recommended practice here as well. I would recommend three: Whether or not free is explicitly called, all allocated memory is reliably freed at program exit. Space allocated by malloc is guaranteed to be available to the program; no exceptions will result when the program access the memory. Whether freed memory is returned to an underlying operating system and therefore made available to other programs, or merely made available for future allocation by the same program, is unspecified. The second point obviously rules out "lazy allocation" schemes. The third makes it explicit that returning freed memory to the operating system is a valid possibility; I have heard it argued that it somehow is not under the current C Standard. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 76. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.14.3.1 Title: calloc definition Detailed description: I think it is safer to define calloc as being equivalent to malloc(nmemb * size) rather than risking misinterpretations about "arrays" and "objects" (see also comment 61). Also, the "all bits zero" initialization could of course be succinctly defined in terms of memset. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 77. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.14.3.4 Title: realloc description Detailed description: I'd say that the last sentence of the Returns section (para. 3) should be moved to the formal description in para. 2, along with an explicit statement that the former values of both ptr and *ptr are then indeterminate. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 78. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.14.4.1 Title: abort description Detailed description: The words "An implementation-defined form of the status unsuccessful termination is returned to the host environment by means of the function call raise(SIGABRT)" could be interpreted as a recommendation to the programmer of how to get that result, *as opposed to* whatever it is that abort does. I would change "by means of the function call" to "as if by a call to". ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 79. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.14.5 Title: searching/sorting wording Detailed description: In para. 3, it is presumably the implementation *of qsort* which may reorder elements of the array, not the comparison function of the preceding sentence (nor bsearch). I would use plural in para. 4: When the same objects (consisting of size bytes, irrespective of their current position in the array) are passed more than once... ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 80. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.14.5 Title: qsort/bsearch example Detailed description: An example might be nice: After declaring char *sarray[100]; int pstrcmp(const void *p1, const void *p2) { return strcmp(*(char * const *)p1, *(char * const *)p1); } and after filling in the array sarray with 100 pointers to strings, the call qsort(sarray, 100, sizeof(char *), pstrcmp) will sort them, and the call char *p =3D bsearch("test", sarray, 100, sizeof(char *), pstrcmp); will search for the string "test". ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 81. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.14.6.2 Title: div wording Detailed description: I would replace "of the division" with "resulting from the division", and I might add "If denom is 0 or" before "if the result cannot be represented." ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 82. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.15 Title: centralized non-overlap wording Detailed description: If the undefinedness of copying between overlapping regions is asserted just once, up front (see comment 7), it could be removed from the individual subsections of this section. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 83. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.15.5.7 Title: typo #8 Detailed description: A period is missing at the end of para. 2. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 84. Category: Feature that should be included Committee Draft subsection: 7.15.5.8 Title: safer strtok Detailed description: Following the precedent set by wcstok (sec. 7.19.4.5.7), there should really be a strtok variant (some implementations call it strtok_r) which accepts a pointer to the pointer storage to be used between calls. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 85. Category: Normative change to intent of existing feature Committee Draft subsection: 7.16.1 Title: tm_extlen default value Detailed description: Following the Internet rule of "Be conservative in what you send, liberal in what you accept", I believe that tm_extlen should be specified as being 0 if tm_ext is a null pointer (para. 5). Leaving it unspecified buys nothing, and only invites needless errors. (If this change is made, the lists in Annex K will of course have to be updated.) ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 86. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.16.2.3 Title: mktime verbiage Detailed description: Paragraphs 5 and 6 repeat too much of paragraphs 3 and 4. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 87. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.16.2.4 Title: mkxtime wording Detailed description: In paragraph 2, "into account of" should be either "into account" or "account of". Also, "of struct tmx" could be usefully added at the end of that sentence. In paragraph 3, "include the effects" should probably be "including the effects". There is no Returns section. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 88. Category: Other (comment) Committee Draft subsection: 7.16.3.5 Title: misc. wording #4 (zonetime) Detailed description: More precisely, if the implementation cannot determine the relationship between the implementation's time and the requested zone. (Para. 2.) (Also, the pronoun "that" in para. 3 is vague.) ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 89. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.16.3.6 Title: strftime description Detailed description: The reason for the bracketed member names in the list of conversion specifiers in para. 2 should be explained. (Presumably they are the ones containing "values contained in the structure" relevant to that specifier.) For %x and %X, "[all specified in 7.6.1]" would more fully be "[all fields specified in subclause 7.6.1]". For %Z, I presume that the time zone name or abbreviation may be locale-specific. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 90. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.18.2.1 Title: misc. wording #5 Detailed description: I can't parse the first sentence of para. 2. I think what it's trying to say is For wide characters corresponding to regular characters, and/but with the exception of..., each of the following functions... ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 91. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.18.2.1.1 Title: typo #9 Detailed description: Th first word of para. 2 is misspelled. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 92. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.18.2.1.3 Title: typo #10 Detailed description: There's an extra "for" in the first sentence of para. 2. Also, the comma after "set of characters" is unnecessary, and the words "the following:" get in the way, and could be removed. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 93. Category: Request for information/clarification Committee Draft subsection: 7.18.2.1.0 Title: iswspace definition Detailed description: Saying "none of iswalnum, iswgraph, or iswpunct" seems redundant, because I believe iswgraph tests for the union of iswalnum and iswpunct. Also, the relationship (inclusive or exclusive) to iswcntrl is not mentioned. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 94. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.19.1 Title: misc. wording #6 Detailed description: In paragraph 10, there are now *two* functions for wide-string date and time conversion. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 95. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.19.2.1 Title: fwprintf wording (too much of) Detailed description: Given that fwprintf's description is nearly identical to fprintf's, it could (and I think should) be replaced with The fwprintf function is equivalent to the fprintf function (see section 7.13.6.1), except that: the format string pointed to by fmt is a wide character string; the various characters expected in the format string, and the characters written to the output stream, are all wide characters; wherever 7.13.6.1 refers to n-char-sequence, fwprintf uses n-wchar-sequence; [though there's no difference?] for the %c format specifier, if no l qualifier is present, the int argument is converted to a wide character as if by calling btowc, and the resulting wide character is written; for the %c format specifier, if an l qualifier is present, the wint_t argument is converted to wchar_t and written; and for the %s format specifier, the behavior/ description is [as now described in the working draft section 7.19.2.1]. I believe that this list is complete, especially if the changes suggested in comment 45 are incorporated. See also my comment 73 for additional justification for this change. (I might also point out that section 7.19.5 already uses this sort of wording to define wcsftime in terms of strftime, so there's a precedent.) If fwprintf's text is not coalesced with fprintf's: the extra sentence at the end of para. 2 should be discarded; the discrepancy (noted in comment 46) with respect to %hhn should be rectified; and the first paragraph under "Recommended practice" should be numbered. Also, I believe the example should be omitted; it is so similar to fprintf's example that it serves no useful purpose. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 96. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.19.2.2 Title: fwscanf wording (too much of) Detailed description: Given that fwscanf's description is nearly identical to fscanf's, it could (and I think should) be replaced with The fwscanf function is equivalent to the fscanf function (see section 7.13.6.2), except that: the format string pointed to by fmt is a wide character string; the various characters expected in the format string, and the characters read from the input stream, are all wide characters; the (optional) maximum field width in a conversion specifier specifies a count of wide characters; a directive that is an ordinary wide character [in the format string] is expected to match a wide character read from the input stream; input white-space characters (to be skipped in response to white-space directives and before conversion specifiers other than %[, %c, and %n) are as specified by the iswspace function; { input performed by the %d and %i specifiers is converted as if by a call to the wcstol function / the input expected by the %d and %i specifiers is of the same format as that expected for the subject sequence of the wcstol function }; { input performed by the %o, %u, and %x specifiers is converted as if by a call to the wcstoul function / the input expected by the %o, %u, and %x specifiers is of the same format as that expected for the subject sequence of the wcstoul function }; { input performed by the %a, %e,, %f and %g specifiers is converted as if by a call to the wcstod function / the input expected by the %a, %e, %f and %g specifiers is of the same format as that expected for the subject sequence of the wcstod function }; for the %[, %c, and %s format specifiers, the behavior/description is [as now described in the working draft section 7.19.2.2, or try to coalesce if you like]. I believe that this list is complete. See also my comment 73 for additional justification for this change. If fwscanf's text is not coalesced with fscanf's: several of my suggestions from comment 51 apply analogously; the typo in the description of %[ should be fixed ("f no l qualifier is present"); and the missing period at the end of %%'s description should be supplied. Also, I believe the examples should be omitted; they are so similar to fscanf's examples that they serve no useful purpose. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 97. Category: Other (comment) Committee Draft subsection: 7.19.2.5 Title: swprintf confusion Detailed description: It was wrong to have given swprintf its current functionality without naming it snwprintf or swnprintf, and the confusion is compounded now that snprintf's return value is specified so differently. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 98. Category: Other (comment) Committee Draft subsection: 7.19.3.1 Title: fgetwc description Detailed description: Is there anything to be said about the orientation (byte/wide) of the stream? (Ditto, I suppose, for fputwc.) ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 99. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.19.3.9 Title: typo #11 Detailed description: A close parenthesis is missing after the second instance of "pointed to by stream". ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 100. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.19.4.1.1 Title: wcstod wording (too much of) Detailed description: Given that wcstod's description is nearly identical to strtod's, it could (and I think should) be replaced with The wcstod function is equivalent to the strtod function (see section 7.14.1.5), except that: where strtod expects certain characters (including those referred to in subclause 6.1.3.1), wcstod expects the corresponding wide characters; initial white-space characters (to be skipped) are as specified by the iswspace function; wherever 7.14.1.5 refers to n-char-sequence, fwprintf uses n-wchar-sequence; [though there's no difference?] and paragraphs 6 and 7 are swapped :-). I believe that this list is complete. See also my comment 73 for additional justification for this change. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 101. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.19.4.1.1 Title: n-wchar-sequence definition Detailed description: Is the definition of n-wchar-sequence any different from n-char-sequence? Also, these two sequences are missing from Annex B. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 102. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.19.4.1.4 Title: wcstol wording Detailed description: Given that wcstol's description is nearly identical to strtol's, it could (and I think should) be replaced with The wcstol function is equivalent to the strtol function (see section 7.14.1.8), except that: where strtol expects certain characters (including those referred to in subclause 6.1.3.2), wcstol expects the corresponding wide characters; the various characters expected in the input string are all wide characters; and initial white-space characters (to be skipped) are as specified by the iswspace function. I believe that this list is complete. See also my comment 73 for additional justification. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 103. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.19.4.1.6 Title: wcstoul wording Detailed description: Given that wcstoul's description is nearly identical to strtoul's, it could at the very least be replaced with The wcstoul function is equivalent to the strtoul function (see section 7.14.1.10), except that: where strtoul expects certain characters (including those referred to in subclause 6.1.3.2), wcstoul expects the corresponding wide characters; the various characters expected in the input string are all wide characters; and initial white-space characters (to be skipped) are as specified by the iswspace function. I believe that this list is complete. On the other hand, wcstoul could be defined even more succinctly in terms of wcstol, analogous to my comment 73 (q.v. for more justification for this suggestion). ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 104. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.19.4.6 Title: typo #12 Detailed description: I believe a comment is missing after "affected by locale" in para. 1. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 105. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.19.7 Title: misc. wording #7 Detailed description: The parameter name ps appears in para. 4 out of a clear sky. It could be introduced in para. 2: "...take as a last argument a pointer, ps, to an object...". ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 106. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.19.7.3.1 Title: typo #13? Detailed description: In paragraph 3, should the word "or" be inserted before "a value"? ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 107. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.19.7.3.2 Title: typo #14? Detailed description: In paragraph 4, ion the subparagraph for positive return, I believe the comma should be a semicolon. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 108. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.19.7.4.1 Title: mbsrtowcs specification Detailed description: Should the src parameter have type const char * restrict * restrict? In para. 2, should there be a comma after "pointed to by src"? If an encoding error occurs, is the pointer pointed to by src unchanged, unspecified, or undefined? (Para. 4). These comments all apply to wcsrtombs (sec. 7.19.7.4.2), as well. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 109. Category: Editorial change/non-normative contribution Committee Draft subsection: Annex B Title: n-char-sequence in syntax summary? Detailed description: As I've mentioned elsewhere, neither n-char-sequence (sec. 7.14.1.5) nor n-wchar-sequence (sec. 7.19.4.1.1) appear. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 110. Category: Editorial change/non-normative contribution Committee Draft subsection: Annex C Title: printf sequence points Detailed description: Section 7.13.6 implies that "there is a sequence point after the actions associated with each specifier." ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 111. Category: Request for information/clarification Committee Draft subsection: Annex E Title: misc. wording #8 Detailed description: What are FLT_EVAL_METHOD and FLT_ROUNDS doing there between paragraphs 2 and 3? ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 112. Category: Editorial change/non-normative contribution Committee Draft subsection: Annex I Title: typo #15? Detailed description: My copy of Unicode spells Cyrillic with two l's. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 113. Category: Editorial change/non-normative contribution Committee Draft subsection: Annex J Title: warnings about warnings Detailed description: I would *not* say that warnings about converting "a pointer to void to a pointer to any type other than a character type" are common. (It's C++ that requires casts on every call to malloc, not C.) Warnings about functions with return statements with and without expressions should no longer be required, given that changes to sec. 6.6.6.4 (I believe) make these errors now. I'd say it's poor to warn about unrecognized pragmas. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 114. Category: Editorial change/non-normative contribution Committee Draft subsection: K.2 Title: not-so-undefined behavior Detailed description: Many of the bullet items in section K.2 are strange, and do not seem to correspond to language in the draft Standard. Here are a few: The first character of an identifier is a digit (6.1.2). [not possible, I'd say] The same identifier is used more than once as a label in the same function (6.1.2.1). [not possible, I'd say] A trap representation is produced by a side effect that modifies any part of the object by an lvalue expression that does not have character type. (6.1.2.8.1). [may be okay, but I can't parse it] The whole-number and fraction parts of a floating constant are both omitted (6.1.3.1). The period and the exponent part of a decimal floating constant are both omitted (6.1.3.1). Conversion between two pointer types produces a result that is incorrectly aligned (6.2.1.3). [6.2.1.3 is about floating-point types; this identical text appears 6 more bullets down under 6.2.2.3] Non-integer operands are used with a bitwise operator (6.3). ----------------------------------------------------------------- PUBLIC REVIEW COMMENT #9 ISO/IEC CD 9899 (SC22N2620) Public Comment Date: 1998-03-03 Author: Steve Summit Author Affiliation: individual Postal Address: 5812 15th Ave. NE Seattle, WA 98105 USA E-mail Address: scs@eskimo.com Telephone Number: +1 206 522 7534 Fax Number: n/a Number of individual comments: 42 ----------------------------------------------------------------- [begin boilerplate] Before I dive in with my comments, I have several apologies and disclaimers. I'm sorry that these comments are coming in at the last minute, and that there are so many of them. Most of them, at least, are editorial; I haven't made too many normative suggestions. My main goal is to help keep the revised document up to the high standards (for succinctness and accuracy) of its predecessor. I do not require feedback on any of these suggestions. I fully understand (without rancor) that many of them will not be used; the committee member(s) reviewing them need not feel guilty about abandoning them, and need not apologize to me for doing so. Where I have categorized a comment as "Request for information/ clarification", it is invariably a rhetorical question suggesting that the Draft's wording may need to be clarified; I am not requesting a personal response. I apologize, too, for the naivete which I'm sure some of these comments will display. I haven't kept up with the committee's work as much as I'd like, and some of the issues which I've expressed confusion about may well be straightforward. (On the other hand, I'm not completely uninformed about C, as I have been programming in it for about 20 years, maintaining the Usenet FAQ list on it for the past 10, and teaching it for the past 5.) Where I offer suggested new wording, I use two notations to suggest alternatives: words in square brackets [] are optional, and words between braces, separated by slashes (e.g. {this/that/the other}) are alternatives to be chosen among. I have scribbled more comments on my printout of the draft than I have had time to present here before the deadline. If any committee member is interested in, and somehow has time for, polishing the wording of the document, I would be happy to pass on more comments in the same vein (restricting them, of course, to editorial changes, non-normative contribution, and requests for clarification). [end boilerplate] I have divided my comments into three separate submissions. This one (the third) contains editorial comments and suggestions of a somewhat more nit-picky nature which the committee should feel even more comfortable about abandoning (or ignoring entirely). The first submission covers sections (clauses?) 1 through 6, and the second covers section 7 and a few of the annexes. (Because these comments are all minor and editorial, they don't inspire interesting titles, and I beg the committee's pardon in advance for not even making the effort to come up with a descriptive title for more than one of them.) ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 1. Category: Editorial change/non-normative contribution Committee Draft subsection: 5.1.1.1 Title: misc. wording #1 Detailed description: The clause ", in this International Standard" in para. 1 is extremely awkward, and invites being read as the place where program text, source files, and/or preprocessing files are stored. Rather than trying to reword or relocate the clause, I'd say it could simply be omitted. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 2. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.1.2.5 Title: misc. wording #2 Detailed description: In the last sentence of para. 3, I'd omit the word "just". ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 3. Category: other (comment) Committee Draft subsection: 6.1.2.5 Title: misc. wording #3 Detailed description: The keyword `signed' appears out of a clear sky in para. 14, somewhat awkwardly. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 4. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.1.2.5 Title: misc. wording #4 Detailed description: It seemed to me that para. 19 belonged next to para. 14. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 5. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.2.1.1 Title: confusing wording on promotable types Detailed description: In para. 3, the words "the original type" have a mildly vague antecedent. They really mean "the type being used instead" (although that wording's obviously worse). ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 6. Category: Other (comment) Committee Draft subsection: 6.2.2.2 Title: misc. wording #6 Detailed description: I don't think there are any contexts where "a void expression is required"; the likely candidates (secs. 6.3.17, 6.6.3, and 6.6.5.3) all merely say that the expression (of presumably any type) is "evaluated as a void expression". ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 7. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.2.2.3 Title: misc. wording #7 Detailed description: In para. 7, "pointed-to type" (i.e. with an added hyphen) might read more clearly. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 8. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.3.1.1 Title: misc. wording #8 Detailed description: Please make sure (by using \^, or whatever) that the underscores are distinct in the section head, table of contents, index, etc., as they are in the body of para. 1. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 9. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.3.2.1 Title: misc. wording #9 Detailed description: The antecedent of the word "that" in "that in turn" is ambiguous. (Is it "the results", the "array of five ints", or "the expression x[i][j]"?) ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 10. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.3.2.2 Title: misc. wording #10 Detailed description: Paragraph 10's point would be made more strongly if it used the words "actual arguments". ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 11. Category: Request for information/clarification Committee Draft subsection: 6.3.3.3 Title: misc. wording #11 Detailed description: Is "the integral promotion" singular now? ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 12. Category: Other (comment) Committee Draft subsection: 6.3.6 Title: misc. wording #12 Detailed description: I have to say, those two parentheticals in paras. 2 and 3 sound pretty retarded, and don't seem to add much. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 13. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.4 Title: misc. wording #13 Detailed description: I'd find footnote 85 a bit clearer with the word "initialization" or "initializing" inserted before "expression". ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 14. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.5.2.1 Title: misc. wording #14 Detailed description: The words "of this" in para. 10 are awkward, and the pronoun has no antecedent. I'd simply delete both words. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 15. Category: Other (comment) Committee Draft subsection: 6.5.2.1 Title: misc. wording #15 Detailed description: A "flexible array member"?? (Para. 15.) I'm sorry, but I suspect that most of us will continue to call it "the struct hack" (or perhaps, "the new, legitimate struct hack"). ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 16. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.5.5.1 Title: misc. wording #16 Detailed description: I might add "(which shall also not be modified)" at the end of the sentence ending in "to point to another object" in the example paragraph 3. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 17. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.5.6 Title: misc. wording #17 Detailed description: The word "desired" in para. 2 seems wrong; I might suggest "necessary". Also, the second sentence is easy to misread -- it really needs parentheses for grouping, i.e. "a declaration for (a function or an object) of that type". I'm not sure how to fix it, although part of the problem is simply the use of both indefinite articles. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 18. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.5.7 Title: misc. wording #18 Detailed description: The construction "specifies the type specified" in para. 2 is awkward, but I don't know how to fix it. I might add the word "along" between "shall be evaluated" and "with the typedef name". The construction "declared in ordinary declarators" reads badly; I'd at least change it to "declared in ordinary declarations" or "declared by ordinary declarators". ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 19. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.5.8 Title: misc. wording #19 Detailed description: Paragraph 3 might read better with the alternatives interchanged: The type of the entity to be initialized shall be an object type that is not a variable length array type or an array of unknown size. I observe (though this probably doesn't ever rate a footnote) that "object type that is not a variable length array type" perforce includes arrays of known size. In paragraph 6, is it obvious that "any nonnegative value is valid" means only that it is syntactically valid, but that the implementation might complain if a large value caused an object to be too large? ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 20. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.5.8 Title: misc. wording #20 Detailed description: "that member" in para. 13 has a vague referent. Should the word "below" in para. 15 be "herein"? In para. 20, "these rules" might be better than just "the rules". ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 21. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.5.8 Title: misc. wording #21 Detailed description: In example 7, towards the end, I would change "that is initialized" to "and initializes it". ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 22. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.6.4.2, 6.6.6.1 Title: misc. wording #22 Detailed description: The first sentence of section 6.6.4.2 para. 1 is pretty awful, but I'm afraid I don't have any suggestions for fixing it. Section 6.6.6.1 para. 1 isn't much better. In both sections, removing the words "to a... statement... in the block (or an enclosed block)" might help; these words add much to the cumbersomeness and seemingly nothing to the meaning (i.e. my reading of the paragraphs is the same with those words removed). ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 23. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.6.6.1 Title: misc. wording #23 Detailed description: Example 1 is a heroic attempt to make an example realistic, for once, but I'm afraid it was lost on me. Jumping into blocks is a capability that clearly exists but is just as clearly almost always a bad idea; given those facts, I just couldn't motivate myself to wrap my brain around the tortured justification, nor (I think) would my understanding of the issue of jumping into blocks have changed if I had. I'd omit that example. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 24. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.7.1 Title: misc. wording #24 Detailed description: The verb tenses in paragraph 10 are inconsistent. The three instances of "shall be" clash with other instances of "are", and should all be changed to "is" (unless the are's are changed to shall's as well). ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 25. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.7.1 Title: misc. wording #25 Detailed description: At the end of example 1, I'd say that the second form *does* not. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 26. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.8 Title: misc. wording #26 Detailed description: In the syntax description, I'd define `lparen' as "a left parenthesis character not preceded by any whitespace." ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 27. Category: Editorial change/non-normative contribution Committee Draft subsection: 6.8.3.2 Title: misc. wording #27 Detailed description: In para. 1, I might replace "parameter" with "parameter name". In para. 2, I might replace "between" with "within" or "among". ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 28. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.1.2 Title: misc. wording #28 Detailed description: In para. 3, I'd replace "included" with "searched for". The exception for in para. 4 is imperfectly worded. What it's trying to say, of course, is that the effect of including multiple times depends on the instantaneous definition of the NDEBUG macro. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 29. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.1.6 Title: misc. wording #29 Detailed description: In the description of offsetof, strictly speaking, what we need is that the member-designator *and type* are such that... ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 30. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.4 Title: misc. wording #30 Detailed description: At the end of para. 2, I'd say that *many* of these names *will* denote the same type! ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 31. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.4.4 Title: misc. wording #31 Detailed description: With respect to footnote 152, I'm not sure how typical it is for printf and scanf format strings to be different; in my own work, I try to keep them identical. I'd replace "typically" with "in the general case", and "are required" with "may be required". ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 32. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.7.3.5 Title: misc. wording #32 Detailed description: I'd say that "doesn't" in footnote 176 should be spelled out. ----------------------------------------------------------------- ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 33. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.13.3 Title: misc. wording #33 Detailed description: In para. 7, I'd say "As initially opened, the standard error stream..." I think the word "nor" in the second bullet in para. 9 is wrong. ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 34. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.13.5.4 Title: misc. wording #34 Detailed description: I'd delete the word "successfully" in para. 3 -- failure to close the file unsuccessfully (or at all) is ignored, too! ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 35. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.13.6.1 Title: misc. wording #35 Detailed description: I'd add the word "character after % in the description of the %% specifier in para. 6. (For consistency with sec. 7.19.2.1, if nothing else.) ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 36. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.13.6.1 Title: misc. wording #36 Detailed description: Towards the end of the description of %[, I'd change "the next right bracket wide character is the matching right bracket that ends the specification" to "the next following right bracket wide character". ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 37. Category: Editorial change/non-normative contribution Committee Draft subsection: 7/13/6/8 Title: misc. wording #37 Detailed description: In footnote 219, I'd change "invoke" to "do invoke", and "after the return" to "in the caller becomes". ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 38. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.13.7.8 Title: misc. wording #38 Detailed description: putc takes two arguments, so I would change "so the argument" in para. 2 to "so that argument". ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 39. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.13.7.11 Title: misc. wording #39 Detailed description: I'd change "The pushed-back characters" in para. 2 to either "Pushed-back characters" or "The pushed-back character". (I wonder why the plural was used at all, since multiple characters of pushback are of course not guaranteed.) ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 40. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.14.1.5 Title: misc. wording #40 Detailed description: In para. 4, two instances of "like a" are awkward; I'd replace both with "as would be a". ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 41. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.14.2.2 Title: misc. wording #41 Detailed description: I would change "a new sequence" to "the sequence" and "the sequence of pseudo-random numbers shall be repeated" to "the same sequence...". ----------------------------------------------------------------- ----------------------------------------------------------------- Comment 42. Category: Editorial change/non-normative contribution Committee Draft subsection: 7.14.5.2 Title: misc. wording #42 Detailed description: In para. 4, I would say "in the resulting sorted array". PUBLIC REVIEW COMMENT #10 Here are my comments on Draft C9X, in response to your call for comments in . Please let me know if you have any questions or comments about them. ISO/IEC CD 9899 (SC22N2620) Public Comment Date: 1998-03-03 Author: Paul Eggert Author Affiliation: Twin Sun, Inc. Postal Address: 360 N Sepulveda Bl #2055, El Segundo, CA 90245, USA (US = mail) E-mail Address: eggert@twinsun.com Telephone Number: +1 310 524 1800 Fax Number: +1 310 524 1818 Number of individual comments: 14 Comment 1. Category: Editorial change/non-normative contribution Committee Draft subsection: none Title: Introduction to my comments on Draft C9X Detailed description: Here are some comments on Draft C9X from the point of view of a GCC implementer. In the terminology of the standard, GCC is a freestanding compiler, so I'm restricting most of these comments to the compiler proper. I will ignore many of the changes in the standard, as they affect the underlying C library but require no changes to GCC itself. My current expertise is mostly in the preprocessor area, so I'll focus in that area. However, I've also implemented part of the section of the GNU C library, so I'll also comment on changes in that area. Comment 2. Category: Normative change to existing feature retaining the original = intent Committee Draft subsection: 5.1.1.2, 5.2.1, 6.1.2, Annex I Title: Universal Character Names (UCNs): the basic model is wrong Detailed description: Background Draft C9X proposes a new notation (e.g. \u098a or \U0000098A) for including arbitrary ISO 10646 (Unicode) characters in identifiers, strings, and comments. They work as follows: * In translation phase 1, each multibyte source file character is replaced by the corresponding UCN. This occurs very early, even before trigraph replacements. * In translation phase 5 (just after preprocessing), UCNs in char constants and string literals are converted to the execution character set. * Some UCNs are valid in identifiers, but not others. E.g. \u098a (BENGALI LETTER UU) is valid, but \u2110 (SCRIPT CAPITAL I) is not valid. Problems Here are some problems with UCNs as they appear in the current draft. * The current draft assumes that source file characters can be transliterated to Unicode and back again without loss of = information. This assumption is incorrect and unrealistic. For example, = ISO-2022-JP cannot be converted to Unicode without losing information. As a trivial example, ISO-2022-JP distinguishes between `ESC ( B' (which switches to ASCII) and `ESC ( J' (which switches to JIS-Roman); but Unicode discards the distinction between ASCII and JIS-Roman for most characters, as it unifies most of the characters in the two sets. This means that the C9X draft effectively disallows the correct handling of ISO-2022-JP in string literals; an ISO-2022-JP string that contains `ESC ( J' is not guaranteed to contain the same `ESC ( J' after being translated to Unicode and back again. I believe that EBCDIC has a similar problem, as there are multiple representations of `[' in EBCDIC but only one in Unicode. * The use of \u collides with common usage in include directives. For example, `#include "h\ufeed.h"' must be treated equivalently to `#include "h@.h", where @ is Unicode character FEED (ARABIC LETTER WAW ISOLATED FORM). This is not what the programmer likely intended, and C9X must not require this weird sort of case-folding. * The current draft requires that the implementation maintain translation tables from the source and execution character set to Unicode, in order to properly stringize strings. This requirement is unrealistic. Many environments are not using Unicode yet, and do not have such tables. This problem is particularly acute for portable compilers like GCC, as there is no portable standard for accessing such transliteration tables. * The current draft silently changes behavior when stringizing = strings that contain multibyte characters. For example, if @ represents the Unicode character with code FEED (ARABIC LETTER WAW ISOLATED = FORM), then #define str(s) #s printf("\t# of <%s> is <%s>\n", "@", str("@")); outputs something like this: # of <@> is <"\ufeed"> whereas with C89 the program would output # of <@> is <"@"> Clearly the C89 behavior is what is expected. * The current draft precludes a simple implementation that simply treats characters with the top bit on as letters. Such an implementation supports popular encodings like UTF-8 and EUC without having to know what the encoding is. However, the current draft requires that the implementation convert each character to Unicode, which means the implementation must laboriously check for encoding errors, transliterate to and from Unicode, and the like. It also means the user must configure the compiler correctly, to specify which encoding is desired. * The list of UCNs allowed in identifiers is arbitrary and weird. Although the standard seems to allow an implementation to permit almost all UCNs in identifiers, this is not made clear. Suggestion Reword the standard so that UCNs are translated to the source character set in translation phase 1, and are never seen again. Allow an implementation-defined set of source characters in identifiers, using the existing Annex I as a guideline. More specifically, in Section 5.1.1.2 phase 1 change from: Any multibyte source file character not in the basic source character set is replaced by the universal-character-name that designates that multibyte character. to: Any universal-character-name is replaced by a corresponding character in the source character set. The relation between universal-character-names and source characters, and the choice if more than one corresponding source character exists, is implementation-defined. In Section 5.1.1.2 phase 4, remove the following sentence, which is no longer needed: If a character sequence that matches the syntax of a universal-character-name is produced by token concatenation (6.8.3.3), the behavior is undefined. In Section 5.1.1.2 phase 5, remove the phrase ``and universal-character-name''. Remove the existing constraints from Section 5.1.1.2; they are no longer needed. Replace them with the following constraint: In translation phase 1, a universal-character name must = correspond to a character in the source character set. In section 6.1.2, uniformly replace universal-character-name with other-source-character-letter. Add a production other-source-character-letter: A source character letter that corresponds to one of the characters mentioned in Annex I Comment 3. Category: Normative change to existing feature retaining the original = intent Committee Draft subsection: 5.1.1.2, 6.8.3.4, 6.8.6, 6.8.9, etc. Title: standard pragmas should be declarations Detailed description: Background Draft C9X has added six pragmas, which can appear only where declarations can appear. These pragmas do not act as preprocessing directives in any way, except that they are themselves not subject to further preprocessing. These pragmas are inconvenient to explain and use, since they act much like declarations -- e.g. they have scope -- but they do not appear in the language grammar proper, nor can the user easily write a parameterized macro that expands to such a pragma. The rules for where these pragmas can appear are complicated and confusing. In a system where the preprocessor is a separate program, these pragmas will require special treatment in the compiler's lexer and parser, since they do not follow the usual rules for tokenization; e.g. newline is significant. Suggestion Instead of #pragma STDC FP_CONTRACT ON use the syntax pragma STDC FP_CONTRACT ON; Allow standard-pragmas like this to appear at the topmost level, or at the start of a compound statement, by modifying the grammar for external-declaration and compound-statement in the obvious way. You can make `pragma' a keyword if you like, but this isn't = necessary. Once this change is made, there's no need for the pragma operator; it can be removed. Comment 4. Category: Normative change to existing feature retaining the original = intent Committee Draft subsection: 6.8, 6.8.3, 6.8.3.1 Title: The name of __VA_ARGS__ should be specifiable by the user Detailed description: Background Draft C9X introduces a new syntax for macros with varying arguments, = e.g. #define debug(file, format, ...) fprintf(file, format, __VA_ARGS__) Common existing practice, as with GCC, is to use a syntax where the varying arguments are named, e.g. #define debug(file, format, args...) fprintf(file, format, args) Suggestion Allow GCC's syntax for macros with varying arguments. This is an extension to the syntax proposed in draft C9X. It is more readable, as it lets programmers give useful mnemonic names to the varying argument lists, thus improving readability and maintainability. Comment 5. Category: Normative change to intent of existing feature Committee Draft subsection: 7.7.14 Title: Builtin relational operators should be allowed to be quiet Detailed description: Background Draft C9X requires that A need a lot of work and should be withdrawn for = now Detailed description: Background and comments Draft C9X introduced a new time struct tmx, new macros _NO_LEAP_SECONDS and _LOCALTIME, and new functions mkxtime, zonetime, and strfxtime. These new functions seem to be an invention of the committee; they are not based on existing practice, and in some cases even ignore longstanding existing practice. The new functions do not address many of the common problems observed with the C89 primitives, notably with mktime. Nor do they add much functionality. For example, a common extension to C, now required by POSIX.1, are reentrant versions of localtime, gmtime, etc. This fills a genuine need, but it's not addressed by draft C9X. There are also other genuine needs that are not addressed; just look at, say, the harsh words about mktime expressed by the author of the tide-calculation program XTide in its source code . Draft C9X addresses few of the needs expressed by this author. Here are some more detailed comments on technical shortcomings in this area. Section 7.16.1 paragraph 3. The tm_zone member is an integer number of minutes. However, common practice (e.g. SunOS 4.x, BSD/OS, Linux) is to have a member named tm_gmtoff that is a long number of seconds. This is required for proper support of POSIX.1, which lets the user specify UTC offset to the second; it is also required for proper support of historical applications. For example, the UTC offset of Liberia was 44 minutes and 30 seconds until May 1972, and any program running on, say, Linux with the TZ environment variable set to "Africa/Monrovia" cannot operate correctly with if the UTC offset is required to be a multiple of 60 seconds. The tm_ext and tm_extlen members are an unprecedented kludge in the standard library spec. This is not C++! If the specification for struct tmx is incomplete, this suggests that the editorial work is not done and this type should be withdrawn from the standard. Section 7.16.2.3 paragraph 4. Here, draft C9X added the following new specification for mktime: If the call is successful, a second call to the mktime function with the resulting struct tm value shall always leave it unchanged and return the same value as the first call. (*) This specification is reasonable for mkxtime, but for mktime it requires changes to existing practice in a way that breaks existing software. Existing software often assumes that tm_isdst is either negative, 0, or 1; C89 does not guarantee this, but it is common existing practice, so software that makes this assumption is portable in practice. Unfortunately, specification (*) cannot be satisfied without either adding hidden members to struct tm (which breaks binary compatibility) or by stuffing more information into tm_isdst (which breaks the programs described above). Granted, programs shouldn't assume that a positive tm_isdst is 1, but it's very common in POSIX.1 programs to see expressions like `tzname[tm->tm_isdst]', and these expressions won't work if tm_isdst contains large values. Section 7.16.2.4 paragraph 3. If tm_zone was _LOCALTIME, and if tm_isdst is preposterous (e.g. negative, or INT_MAX), this specification is unclear about what to do. The comments in 7.16.2.6 don't help much. Section 7.16.2.6 paragraph 1. The specification for tm_isdst does not allow for negative daylight-saving time. I don't know of any historical practice for this, but POSIX.1 allows it, and implementations that support POSIX.1 have to allow for it. Section 7.16.2.6 paragraph 2. The limits on ranges for struct tmx members are unreasonable. Common existing practice, for example, is to invoke mktime with a large value for tm_sec to compute a time stamp at some distance from the POSIX.1 epoch. If int and long are the same size, this runs afoul of the new restriction in this section, which limits tm_sec to one-eighth of the potential range. With this limitation I cannot even use mktime to compute today's date on my Unix host from today's time_t value! The other limits are also unnecessary. A well-written mktime should work in the presence of arbitrary values in struct tm members; similarly for mkxtime. Section 7.16.2.6 paragraph 3. There are so many errors in this section that it is hard to determine what is intended. But from what I can tell, the intent is wrong. For example, it seems to be saying that if the implementation supports leap seconds, and if local time is UTC, and if I have a struct tmx that corresponds to 1997-06-30 00:00:00, and then add 1 to tm_mday and invoke mkxtime, I should get 1997-06-30 23:59:60 due to the intervening leap second. This is not what I, the programmer, want or expect! The first sentence in this paragraph reads ``Values S and D shall be determined as follows''. But the rules that follow do not _determine_ S and D; they merely place _constraints_ on S and D. This is because the implementation has some leeway in choosing X1 and X2. It's not clear in this paragraph whether we're looking at C code or mathematics. Are we supposed to be using all the C rules for promotion, conversion, and overflow, or are the calculations to be done using mathematical integer arithmetic? The last sentence in the comment about X1 and X2 is incoherent; I really can't make out what it means. For the implementation to determine X1 and X2, it needs to know what D and S are. But D and S are computed from X1 and X2! More explanation is needed before I can really figure out what's intended here. The definition of D is completely unmotivated, and does not obey the rules of the Gregorian calendar. Among other things, it uses / and % in places where it should use QUOT and REM. (And it can't possibly be right without a `100' in it somewhere. :-) The definition should be rewritten to be something like the following. (Sorry, I haven't tested this, as it's less than 30 minutes before the deadline for submitting comments in the US as this sentence is being written.) D =3D // day offset since 0000-03-01 // contribution from year Z*365 // number of non-leap days since 0000-03-01 + QUOT(Z, 4) // Every 4 years ends in a leap year. - QUOT(Z, 100) // Every 100 years ends in a nonleap year. + QUOT(Z, 400) // Every 400 years ends in a leap year. // contribution from month; note we start from 03-01 + ((int []){ ...yday offsets, starting in March ...}) [REM(M - 2, 12)] // contribution from day of month + tm_mday - 1 // contribution from time of day + QUOT(SS, 86400) except of course that the expression QUOT(SS, 86400) mishandles leap seconds as described above. Section 7.16.3.5 This new function zonetime is if only marginal use; it seems to be present mostly as a way of defining how mkxtime works. The definition of leap seconds is incorrect. Leap seconds are not a UTC-UT1 offset. The absolute value of the difference between UTC and UT1 is at most 0.9 seconds, by definition. The changes to 7.16 seem to be hastily edited: there are a number of what seem to be typographical errors. The changed text is not explained, and the typos make it hard to understand what was intended. Here are some of the typos that I spotted despite these problems: Section 7.16.1 paragraph 2. _LOCALTIME ``must be outside the range [-14400, +14400].'' Presumably this should be [-1440, +1440], i.e. one day's worth not ten. Section 7.16.2.6 paragraph 3. The definition for QUOT yields numerically incorrect results if (b)-(a) or (b)-(a)-1 overflows. I suggest replacing it with the following definition, which is clearer and free of problems with overflow. This definition relies on C9X's new guarantees about integer division. #define QUOT(a,b) ((a)/(b) - ((a)%(b) < 0)) Similarly, REM can overflow if (b)*QUOT(a,b) overflows. Here is a better version. #define REM(a,b) ((a)%(b) + (b) * ((a)%(b) < 0)) The definition of Z can be written more compactly as: Z =3D Y - (M < 2); Section 7.16.3.6 paragraph 5. ``If this value is outside the normal range, the characters stored are unspecified.'' What is the ``normal range''? The range as output by localtime, the range of the Gregorian calendar, or the limits as specified in 7.16.2.6? Suggestion Drop all changes to the section for this revision of the C Standard. Bring in experts in this area for the next revision of the C Standard. I suggest working together with the members of the Time Zone Mailing list . Build on existing practice rather than relying on committee inventions, which have been error-prone in this area. If these suggestions is not followed, a lot of changes are needed to this section, as suggested by the above discussion; please contact me if you need more details. PUBLIC REVIEW COMMENT #11 Subject: Comments on ISO/IEC CD 9899 (C9X) ISO/IEC CD 9899 (SC22N2620) Public Comment Date: 1998-03-03 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 Number of individual comments: 1 ------------------------------------------------------------------------ Comment 1. Category: Request for clarification Committee Draft subsection: 6.5.2.1, 6.1.2.8.2, K.2, K.3.9, K.5.8. Title: Bitfield widths Detailed description: Section 6.5.2.1 #8 states that a bitfield can be declared as type 'int', 'signed int', or 'unsigned int'. It further states that "a bitfield is interpreted as a signed or unsigned integer type consisting of the specified number of bits". However, there is no mention of whether or not the number of bits in a bitfield is limited to the number of bits in an '[unsigned] int'. 6.5.2.1#8 implies that a bitfield can be declared with the number of bits in /any/ integer type. This implies that bitfields can be declared to have any number of bits, up to the number of bits in a 'long' or even a 'long long' integer type. Presumably, then, the following declaration is conforming and portable: struct Widdle { unsigned int a: 29; // Exceeds bits in UINT_MAX unsigned int b: 33; // Exceeds bits in ULONG_MAX }; The width of member 'a' exceeds the minimum ISO width of 'unsigned int' of 16 bits, so it must take on the type of 'unsigned long int'. Similarly, the width of member 'b' exceeds the minimum ISO width of 'unsigned long int' of 32 bits, so it must take on the type of 'unsigned long long int'. This seems like a reasonable interpretation. But is it correct? Sections K.2, K.3.9, and K.5.8 state that a compiler may allow types other than 'signed int' and 'unsigned int' for bitfields as an extension. Assuming that the interpretation above is correct, such extensions are superfluous; all bitfield types would be equivalent, and would only be distinguished by their signedness. Suggestion: The maximum allowable size for a bitfield should be mentioned in the standard, perhaps as a footnote to section 6.5.2.1#8: 6.5.2.1 ... [#8] ... A bitfield is interpreted as a signed or unsigned integer type consisting of the specified number of bits *. * This implies that a bitfield may contain any number of bits, up to the number of bits in the widest integer type (umaxint_t). If instead it is deemed a limitation that bitfields cannot have a width that exceeds the number of bits in an '[unsigned] int', then this should be mentioned, perhaps as a footnote. Further, it should be noted in appendix K that exceeding this limit is implementation-defined behavior.