SC22/WG14 N804 Editor's Report January 30, 1998 This is a revised version of N799 incorporating corrections | and additions. The diff marks indicate changes from the | original version. 1. Status As you know, an editorial committee consisting primarily of Benito, Farance, Jaeschke, Jones, MacDonald, and Walls (with the assistance of Thomas, Gwyn, and others) met in Santa Cruz November 17-20 to prepare the draft for CD ballot. After much work at the meeting and some subsequent formatting clean-up, a final document was prepared on November 24 and forwarded to SC22. That document has since | been distributed to the members of SC22 and made available | on SC22's web page. Various member bodies have announced | its availability and solicited public comments. A | preliminary version of the draft was distributed (via the | committee's web page) as N794; this document has also been | circulated outside the committee as well as within it. Both | documents have generated a fair amount of discussion on the | comp.std.c newsgroup and the committee reflector as well as some private e-mail pointing out errors and omissions. The remainder of this report is based on these comments as well as my own review. 2. CD1 Errata General All of the headings are too small. When the size of the body text was increased, the sizes of the headings were not increased to match. | None of the tables are properly formatted in the text version due to a production error. (The text version has | not been reviewed and undoubtedly contains many other | formatting problems.) | There are many typesetting issues still to be addressed. For example, there are many equations typeset as code and vice versa, particularly in annexes F and G. Some of these issues primarily affect the typeset version and some primarily affect the text version. | Clause 2, Paragraph 1, Page 2 | 2 SC22/WG14 N804 Although one of the references is a technical report, the | introductory text refers only to standards; it should be | revised to include TRs. | The hyphens in the standards' designations should be dashes. | This is also true for other references in the text, | particularly annex A. | The correct date for ISO 4217 is 1995, the correct date for | ISO/IEC TR 10176 is 1998 (also annex A). Clause 3, Paragraph 2, Page 3 The reference to ISO 2382-1 should be to ISO/IEC 2382-1. | 3.18, Paragraph 3, Page 6 | An implementation need not successfully translate a given | program if it exceeds a translation limit. | 5.1.1.2, Paragraph 1, Page 9 | The term ``universal-character-name'' should not be | hyphenated. This is also true for all other occurrences | (other than in the syntax). | Since we now allow concatenation of character and wide | string literals, phase 6 should be rewritten to simply: | Adjacent string literal tokens are concatenated. 5.1.1.2, Forward References, Page 10 There should be a forward reference to 5.2.1 for universal character names. 5.1.2.3, Example 6, Page 16 ``However'' (4th line from the end) should be followed by a comma. 5.2.1.1, Footnote 12, page 19 The reference to ISO/IEC 646:1991 should be to ISO 646. 5.2.4.2.2, Paragraph 6, Page 26 The list of values should be indented like the one in paragraph 5. 6.1 and 6.2, Pages 31-66 The reorganization specified in N672 has not been applied. SC22/WG14 N804 3 6.1.2, Paragraph 2, Page 34 The description of nondigit characters should mention other | characters specified by universal character names. | The reference to annex H should be to annex I. | 6.1.2.5, Footnote 29, Page 40 | In the second line, ``alternate'' should be ``alternative'' | and ``designed'' should be ``designate''. I suggest | rewording the first two sentences to: | An implementation may define new keywords that provide alternative ways to designate a basic (or any other) type; this does not violate the requirement that all basic types be different. 6.1.2.5, Footnote 30, Page 40 In the last line, there should not be a comma after ``two'' and ``it'' should be ``is''. 6.1.2.6, Paragraph 1, Page 42 Near the end of the fifth line, the period after ``following requirements'' should be a colon. | 6.1.4, Paragraph 2, Page 54 | The terms ``character string literal'' and ``wide string | literal'' should be in italics. 6.1.4, Paragraph 6, Page 55 Although this paragraph doesn't contain the magic word ``unspecified'', whether string literals are distinct or not is unspecified and should be added to K.1. 6.1.5, Paragraph 1, Page 55 The definition of operator is missing { and }, although it does have the alternative spellings <: and :>. They should also appear in the constraint. (Also annex B.) 6.1.6, Paragraph 1, Page 56 The definition of punctuator is missing .. (Also annex B.) 6.2.1.1, Paragraph 2, Page 60 The period after ``may be used'' should be a colon. 4 SC22/WG14 N804 6.2.1.3, Footnote 48, Page 61 In the last line, there should be a space after the comma. | 6.3.1.1, Page 69 | In the heading, there should be a thin space between the | underscores. 6.3.2.2, Paragraphs 5-6, Page 72 These paragraphs are almost impossible to read correctly. At the very least, paragraph 6 should be a continuation of paragraph 5, not a new paragraph. My suggestion is to move | paragraph 6 into paragraph 5 between the third and fourth | sentences. I also suggest moving paragraph 7 after | paragraph 8. 6.3.2.5, Example 5, Page 78 In the last line of code, there should be a space before the square brackets. Likewise for example 6. | 6.3.3.3, Paragraphs 2-4, Page 81 In each paragraph, ``the integer promotion is'' should be ``the integer promotions are''. 6.3.6, Paragraph 12, Page 87 In line 2, ``know constant size'' should be ``known constant size''. 6.3.15, Paragraphs 4-6, Page 93 The last clause of paragraph 4 should read: the result of the operator is the value of the second or third operand (whichever is evaluated), converted to the type described below. The first sentence of paragraph 5 should read: If both the second and third operands have arithmetic type, the type that the usual arithmetic conversions would yield if applied to those two operands is the type of the result. Paragraph 6, beginning with the second sentence, should | read: | SC22/WG14 N804 5 Furthermore, if both operands are pointers to compatible types or differently qualified versions of compatible types, the result type is a pointer to an appropriately qualified version of the composite type; if one operand is a null pointer constant, the result has the type of the other operand; otherwise, one operand is a pointer to void or a qualified version of void, in which case the result type is a pointer to an appropriately qualified version of void. 6.5, Paragraph 1, Page 100 | The last production for declaration-specifiers should read: | function-specifier declaration-specifiers-opt 6.5.2, Paragraph 4, Page 103 In the middle of the second line, ``specified'' should be | ``specifier'' and ``is the same type'' should be | ``designates the same type''. | 6.5.2.1, Footnote 91, Page 105 | The remnants of implicit int should be removed; the body | should read: | As specified in 6.5.2 above, if the actual type specifier used is int or a typedef-name defined as int, then it is implementation-defined whether the bit-field is signed or unsigned. 6.5.2.3, Paragraph 3, Page 108 In the second line, ``complete'' should be ``incomplete''. | 6.5.2.3, Paragraph 6, Page 109 | The declaration is missing the trailing semicolon and, in | the last line, ``structure of union'' should be ``structure | or union''. 6.6.4.1, Paragraph 3, Page 142 In the first line, ``preceeding'' should be ``preceding''. (And I'd be grateful if anyone could explain to me why ispell doesn't complain about it.) 6.6.6.1, Example 2, Page 146 In the middle of the block of code, the line ``goto lab 4;'' should be ``goto lab4;''. | 6 SC22/WG14 N804 6.6.6.2, Paragraph 2, Page 147 | The statements in the code blocks are not properly aligned. 6.8.8, Paragraph 2, Page 171 The second line should not appear and the remainder of the paragraph should be formatted as definitions as in the previous paragraph. 6.8.9, Paragraph 1, Page 172 In the third line, the period after ``follows'' should be a | colon and ``string literal'' should not be italicized. 6.8.9, Examples, Paragraph 2, Page 172 In the #pragma, ``list'' should be ``listing''. | 7.1.1, Paragraph 1, Page 174 | The quoted terms should all be italicized (cf. paragraph 6). 7.1.2, Paragraph 1, Page 175 In the last line, ``explicity'' should be ``explicitly''. | 7.1.7, Page 179 | Still need final words for a real boolean type (N738 and | part of N743 were adopted in principle, but no final words | were ever produced). 7.1.7, Paragraph 2, Page 179 In the last line, ``for'' should be ``of''. | 7.1.7, Footnote 138, Page 179 | In the second paragraph, the quotes around ``masked'' should | be real quotes, not double-quotes. 7.1.8, Paragraph 3, Page 181 ``return'' should be ``returns''. (Also annex C.) 7.2.1.1, Paragraph 2, Page 183 In line 4, ``name of the source file, and the source line number'' should be ``name of the source file, the source line number, and the name of the enclosing function''. 7.3.1.3, Page 186 SC22/WG14 N804 7 The isblank function was not approved by the committee and should not have appeared in the draft. | 7.4, Paragraph 1, Page 190 | There should be a footnote pointing to future library | directions (7.20.3). 7.4, Paragraph 3, Page 190 Starting at the end of the first line, ``character constants'' should be ``constants''. 7.4.5, Paragraph 1, Page 199 The reference to footnote 151 should be to 149 instead. | Since footnote 149 is so far away, I suggest replicating it | here or moving this subclause to immediately after 7.4.2. 7.5, Paragraph 3, Page 202 The reference to footnote 153 should be moved to the end of the sentence. | 7.5.1.1, Paragraph 2, Page 203 | In the very last line, there should be a reference to strfxtime as well as strftime. Also a forward reference. | 7.7.8.3, Paragraph 2, Page 236 | In the last line, ``too large'' should be ``too large or too small''. | 7.7.9.3, Paragraph 2, Page 238 | The parenthetical sentence at the end of the paragraph | should be included in the previous sentence and the hyphen | should be the word ``and''. | 7.8, Paragraph 1, Page 249 | There should be a footnote pointing to future library | directions (7.20.8). | 7.8.2.23, Paragraph 2, Page 258 | There should be a reference back to footnote 188. | 7.10.2.1, Paragraph 2, Page 264 | The comma near the end of the second line should be deleted. | It implies that you can only longjmp to the most recent | setjmp, which is clearly not correct. 8 SC22/WG14 N804 7.11, Paragraph 3, Page 266 The portion of the paragraph between the two lists should read: which expand to constant expressions with distinct values that have type compatible with the second argument to, and the return value of, the signal | function, and whose values compare unequal to the address of any declarable function; and the following, which expand to positive integer constant expressions with type int and distinct values that are the signal numbers... 7.11.1.1, Paragraph 3, Page 267 | In the fourth line, ``occuring'' should be ``occurring''. | 7.13.2, Paragraph 5, Page 277 | In the first line, there should not be a semicolon before | ``and''. | In the third line, the phrase ``and are not affected by'' | should be set off by commas. | 7.13.2, Forward references, Page 278 | The entries should be the actual section titles, not just | the names of the functions. | 7.13.3, Paragraph 11, Page 279 | ``getwc'' should be ``fgetwc''. | 7.13.3, Forward references, Page 280 | The reference for ``conversion state'' should be 7.19.6, for | mbrtowc should be 7.19.6.3.2, and for wcrtomb should be | 7.19.6.3.3. 7.13.6.1, Paragraph 3, Page 288 In the list item beginning ``An optional hh...'', the words for hhn have been omitted. | 7.13.6.1, Paragraph 3, Page 291 | In the description of the c conversion specifier, at the end | of the second line, ``Otherwise'' should be ``If an l | qualifier is present'' and should start a new paragraph | (cf., the s conversion specifier). | SC22/WG14 N804 9 7.13.6.1, Footnote 213, Page 292 | The reference should be to 7.20.6. 7.13.6.1, Paragraph 14, Page 293 The heading should read "Environmental limits". | 7.13.6.2, Paragraph 11, Pages 297-298 In the descriptions of the s, [, and c conversion | specifiers, there should be a paragraph break before the | sentence beginning ``If no l qualifier is present...''. | The reference to footnote 216 should be replicated in the | descriptions of the [ and c conversion specifiers. | 7.13.6.2, Footnote 216, Page 297 | There should be an ``and'' before c. | 7.13.6.2, Footnote 217, Page 299 | The reference should be to 7.20.6. | 7.13.6.2, Example 3, Page 301 | The last block of code is too wide; it should be reformatted | to fit within the margin. | 7.13.7.11, Paragraph 5, Page 314 | There should be a footnote at the end of the paragraph | pointing to ``future library directions'' (7.20.6). | 7.14, Footnote 221, Page 321 | The reference should be to 7.20.7. | 7.14.2.1, Paragraph 5, Page 330 | The heading should read "Environmental limits". 7.14.5, Footnote 227, Page 336 The last line of the footnote is missing. It should read: (char *)p < (char *)base + nmemb * size 7.15.1, Footnote 232, Page 345 | The reference should be to 7.20.9. 10 SC22/WG14 N804 7.16.1, Paragraph 1, Page 357 In the first line, ``four types and several functions'' should be ``several types and functions''. | 7.16.1, Paragraph 3, Page 357 | The wording for struct tm and struct tmx should be revised | to clarify that both hold broken-down times. 7.16.2.3, Paragraphs 5-6, Page 360 The last sentence of paragraph 5 and all of paragraph 6 | should be deleted. | 7.16.2.4, Paragraph 2, Page 361 | At the end of the line, ``takes into account of the | additional members'' should be ``takes into account the | values of the additional members''. | 7.16.2.5, Paragraph 2, Page 362 | ``L'' should be italicized throughout this paragraph. 7.16.2.6, Paragraph 3, Page 363 At the end of the block of // comments, there should be one more: // if the offset cannot be determined. 7.16.3.6, Paragraphs 2-6, Pages 367-369 | The typography throughout this section is inconsistent, | particularly the use of program font and double-quotes; the | use of == in paragraph 3 is also unconventional. | The hyphens in the range specifications should be dashes. | 7.18.1, Paragraph 2, Page 371 | At the end of the description of wint_t, there should not be | a period before the parenthetical remark, the parenthetical | remark should not start with an upper case letter and should | not end with a period, and a semicolon should follow the | parenthetical remark. | At the end of the description of wctrans_t, the comma should | be a semicolon. | 7.18.1, Footnote 241, Page 371 | The reference should be to 7.20.10. | SC22/WG14 N804 11 7.18.2.1, Paragraph 3, Page 372 | This should be a normal Forward References section -- it | should not have a paragraph number and the heading should be | in bold font. 7.18.2.1.1, Paragraph 2, Page 373 ``Th'' should be ``The''. 7.18.2.1.3, Page 373 The iswblank function was not approved by the committee and should not have appeared in the draft. 7.18.2.2, Paragraph 1, Page 376 The reference to subclause 4.5.2.1 should be to 7.18.2.1. | 7.19.1, Footnote 247, Page 380 | The reference should be to 7.20.11. | 7.19.1, Paragraph 2, Page 380 | The comma at the end of the first line should be a | semicolon. | 7.19.1, Paragraph 3, Page 380 | The comma near the end of the third line should be a | semicolon and there should not be a paragraph number. | 7.19.1, Paragraph 4, Page 380 | The period at the end of the line should be a semicolon | followed by ``and'' and there should not be a paragraph | number. | 7.19.1, Paragraph 5, Page 380 | There should not be a paragraph number and this should read: | struct tm and struct tmx which are declared as incomplete structure types, the contents of which are described in subclause 7.16.1. 12 SC22/WG14 N804 7.19.1, Paragraph 6, Page 380 | The comma at the end of the first line should be a | semicolon. | 7.19.1, Paragraph 7, Page 380 | The comma at the end of the first line should be a semicolon | and there should not be a paragraph number. | 7.19.1, Paragraph 8, Page 380 | The comma near the end of the first line should be a | semicolon and should not be in program font, and there | should not be a paragraph number. | 7.19.1, Paragraph 9, Page 380 | There should not be a paragraph number. 7.19.2.1, Paragraph 2, Page 381 The last sentence is duplicated. 7.19.2.1, Paragraph 2, Page 382 In the list item beginning ``An optional hh...'', the words for hhn have been omitted. | 7.19.2.1, Paragraph 7, Page 386 | In the description of the c conversion specifier, near the | beginning of the third line, ``Otherwise'' should be ``If an | l qualifier is present'' and should start a new paragraph | (cf., the s conversion specifier). | 7.19.2.1, Footnote 255, Page 387 | The reference should be to 7.20.11. 7.19.2.1, Paragraph 14, Page 388 The heading should read "Environmental limits". | 7.19.2.1, Paragraph 16, Page 388 This should be a normal Forward References section -- it should not have a paragraph number and the heading should be | in bold font. 7.19.2.2, Paragraph 11, Pages 391-392 In the descriptions of the s, [, and c conversion | specifiers, there should be a paragraph break before the | SC22/WG14 N804 13 sentence beginning ``If no l qualifier is present''. | In the description of the s conversion specifier, the | paragraph beginning ``Otherwise'' should begin ``If an l | qualifier is present'' (cf., the [ conversion specifier). | In the second line of the description of the [ format | specifier, ``f'' should be ``If''. | 7.19.2.2, Footnote 258, Page 392 | The reference should be to 7.20.11. 7.19.2.2, Examples, Page 393 There should not be numbered paragraphs in the examples. 7.19.2.2, Paragraph 22, Page 394 This should be a normal Forward References section -- it should not have a paragraph number and the heading should be | in bold font. | 7.19.4.6.2, Paragraph 1, Page 421 | The prototype is not parallel to memcmp; neither s1 nor s2 | should be restrict qualified, and s1 should be a pointer to | const. | 7.19.5 and 7.19.6, Pages 422-423 | These should be sub-subclauses of a new subclause titled | ``Wide-character time conversion functions''. | 7.19.7.3.1, Paragraph 3, Page 426 | ``a value between'' should be ``or a value between''. 7.19.7.3.1, Paragraph 4, Page 426 This should be a normal Forward References section -- it should not have a paragraph number and the heading should be | in bold font. | 7.20.11, Paragraph 2, Page 433 | Should note that other characters may be used in extensions | (cf., 7.20.6, paragraph 1, page 432). Annexes The annexes and the index are all formatted wider than the main text. | 14 SC22/WG14 N804 Annex C, Paragraph 2, Page 451 | There should also be entries for the sequence points within | library functions specified in 7.13.6, 7.19.2, and 7.14.5. | F.1, Paragraph 1, Page 485 | The standards' designations should not be in italics, only | the titles. | F.1, Footnote 275, Page 488 | Both occurrences of ``IEEE'' should be ``ANSI/IEEE''. F.9.3.11, Paragraph 1, Page 501 In the second bullet item, there should be a space between ) and ``returns''. G.5, Paragraph 5, Page 514 The reference to subclause 7.9.2 should be to 7.8.2. | Annex H, Pages 522-527 | The hyphen in ``LIA-1'' should be a dash. | H.2.2, Paragraphs 1 and 3, Page 522 | The double-quotes should be real quotes. | H.2.4, Paragraph 1, Page 525 | The ugly arrows should be replaced by real arrows. | There should not be spaces between the casts and the | variable names. | K.2, Page 539, Item 3 | The reference should be to 6.5.5.3 (and the item should be | moved in the list appropriately). | K.2, Page 544, Item 5 | strfxtime, wcsftime, and wcsfxtime should be listed in | addition to strftime. (Similar changes to page 545 items 1 | and 7, and page 547 items 1 and 2; and K.3.12 page 554 item | 6.) | K.4, Page 555 | In item 8, isblank (7.3.1.3) should not appear in the list. | SC22/WG14 N804 15 In item 18, iswblank (7.18.2.1.3) should not appear in the | list. Index, Pages 559-570 The index, which was produced manually, is both incomplete and inaccurate. I have since reviewed and corrected it and used that information to continue the process of adding index macros to the text so as to generate the index automatically as part of the formatting process. I have also added the automatic index generation to the formatting process and have produced an enhanced and corrected index to CD1 (N800) which can be used to aid in the review process. Note that there is still a lot of work to be done on the index; I would appreciate any suggestions for additional entries, additional cross references, missing references, or excessive references. 3. Suggested Editorial Changes General References to other standards should not include specific * versions except in the References and Bibliography. | 3.17, Paragraph 1, Page 5 | I think this would read better if ``specification that is'' | was changed to ``specifications that are''. (Also in other | places, particularly annexes F and G.) | 5.1.1.2, Paragraph 2, Page 10 | This is a peculiar place for a constraint since there is no | syntax for it to constrain. It should be moved to where the | syntax is, currently 5.2.1 on page 19. | 5.2.1 Paragraph 4, Page 19 | This is a peculiar place to have syntax, since the syntax | isn't even described until clause 6. I suggest leaving the | first sentence here but moving the syntax and all of | paragraph 5 (along with the related constraint from 5.1.1.2) | into 6.1.2 (Identifiers). I also suggest changing the description to: The universal character name \Unnnnnnnn designates the character whose character short identifier (as specified by ISO/IEC 10646-1) is nnnnnnnn. Similarly, the universal character name \unnnn designates the character whose character short 16 SC22/WG14 N804 identifier is 0000nnnn. 5.2.4.2.2, Paragraph 7, Page 26 | A better wording is: | The values given in the following list shall be replaced by implementation-defined expressions with values that are greater or equal in magnitude (absolute value) to those shown, with the same sign: 5.2.4.2.2, Paragraph 8, Page 27 | A better wording is: | The values given in the following list shall be replaced by implementation-defined expressions with values that are greater than or equal to those shown: 5.2.4.2.2, Paragraph 9, Page 28 A better wording is: The values given in the following list shall be replaced by implementation-defined expressions with [positive?] values that are less than or equal to those shown: Note that ``positive'' is implied by the float-point model, | but it might be worth repeating. | 6.1.1, Paragraph 2, Page 33 | When discussing imaginary, I think it would be clearer to | say: ... the token imaginary is reserved in translation | units where the header is included and | defines the macro _Imaginary_I; The current wording implies that the program needs to define | _Imaginary_I rather than the header. 6.1.3.1, Paragraph 1, Page 47 The definition of hexadecimal digit really belongs in 6.1.3.2 (Integer constants) since there is text there explaining it. It would perhaps be best to switch these two sections. 6.1.3.4, Paragraph 5, Page 50 SC22/WG14 N804 17 The lists of types for constants would be much easier to read as a table. | 6.3.5, Paragraph 7, Page 84 | This paragraph should be merged with paragraph 3. | 6.3.6, Paragraph 10, Page 86 | This paragraph should be merged with paragraph 4. | 6.4, Footnote 84, Page 98 | Since the footnote only talks about integer constant | expressions, it would be better to have the reference on | that term in paragraph 6 rather than where it currently is. 6.5.2.2, Paragraph 5, Page 108 It would be better to say: The type is incomplete until after the } that terminates the list. since that's what we say for structure and union specifiers | (cf., 6.5.2.1, paragraph 6, page 104). | 6.8.8, Paragraph 1, Page 170 | It might be clearer to specify that __LINE__ is the line | number within the current source file and that __FILE__ is | the name of the current source file. | Clause 7, Pages 174-433 | Many of the subclauses (and sub-subclauses) should be | rearranged to put them into alphabetical order. I suggest | moving the headers that are currently under 7.1 out to the | top level (even though that means splitting up and | , neither of which say much); alternatively, | (and, perhaps, ) would need to be | moved into 7.1. I also suggest alphabetizing the individual | functions within each category. | 7.7, Pages 218-248 | A number of subclauses in this section write out equations using words such as ``x raised to the power y''. I suggest using equations in all cases. | 7.7.6.1, Paragraphs 2-3, Page 229 | Since we now have additional exponential functions, this | should be reworded parallel to 7.7.6.7 (The exp2 function) | 18 SC22/WG14 N804 to make the base explicit. | 7.7.6.4, Paragraphs 2-3, Page 230 | Since we now have additional log functions, this should be | reworded parallel to 7.7.6.10 (The log2 function) to make | the base explicit. The note that the base-e logarithm is | the natural logarithm should be kept as a parenthetical | note. 7.7.6.5, Paragraphs 2-3, Page 230 This subclause uses ``base-ten'', other subclauses use ``base-2''; we should be consistent. I suggest using numbers everywhere. I also suggest a parenthetical note | that the base-10 logarithm is the common logarithm since we | note that the base-e logarithm is the natural logarithm. 7.13.3, Paragraph 7, Page 279 Since this paragraph is talking about the standard streams, it might be better to move it to subclause 7.13.2 (Streams). | 7.15.1, Page 345 | There doesn't seem to be any good reason for this being a | subclause; I suggest eliminating the heading. | 7.16.1, Page 357 | There doesn't seem to be any good reason for this being a | subclause; I suggest eliminating the heading. | 7.16.3.6, Paragraph 3, Page 368 | I suggest rewording the second sentence as: | In this system, weeks begin on a Monday and week 1 of the year is the week that includes January 4th, which is also the week that includes the first Thursday of the year. 7.16.3.6, Paragraph 5, Pages 369 | I think it would be clearer if paragraph 5 were merged into | the end of paragraph 2. | 7.18.1, Page 371 | There doesn't seem to be any good reason for this being a | subclause; I suggest eliminating the heading. 7.18.2.1, Paragraph 2, Page 372 SC22/WG14 N804 19 In the second line, it would be better to not mention the exact number of functions (it's easy to overlook if the list ever changes). Similarly for 7.18.2.2.1, paragraph 3, page | 376; 7.18.2.2.2, paragraph 3, page 377; 7.18.3.2.1, | paragraph 3, page 379; and 7.18.3.2.2, paragraph 3, page | 379. | 7.19.1, Page 380 | There doesn't seem to be any good reason for this being a | subclause; I suggest eliminating the heading. | K.2, Page 537, Item 3 | Similarly, converting between a pointer to an object or incomplete type and a pointer to a function causes undefined behavior. Subclause 6.2 is also relevant. | K.2, Page 537, Item 12 | It should be clarified that this only applies to relational comparisons, not equality comparisons. | K.2, Page 538, Item 14 | I think what this is supposed to say is ``An attempt is made to access an object through both a restrict-qualified pointer and another pointer not based on it.'' 4. Suggested Possibly-substantive Changes 6.1.3.1, Paragraph 1, Page 47 In the first two productions for hexadecimal floating constant, the binary exponent part should be optional (parallel to decimal floating constant). | 5. Open Issues General | The text version of the draft has not been reviewed and | contains numerous formatting problems such as superscripts | overprinting information from the previous line and | unintelligible expressions. | There are many typesetting issues still to be addressed. | For example, there are many equations typeset as code and | vice versa, particularly in annexes F and G. Some of these | issues primarily affect the typeset version and some | primarily affect the text version. | 20 SC22/WG14 N804 Still need final words for a real boolean type (N738 and | part of N743 were adopted in principle, but no final words | were ever produced). | All hyphenated terms should be examined to determine where | the hyphenation is appropriate and where it isn't. All | italicized terms should also be examined. | All of the cross references need to be checked for relevance | and accuracy. Clause 4, Paragraph 2, Page 7 Should be added to the list of required headers for freestanding implementations? 6.1, Paragraph 3, Page 31 Are all the italicized terms really appropriate? | 6.1.1, Paragraph 2, Page 33 | It has been suggested that a freestanding implementation | need not support complex types since complex is not a | keyword unless has been included and a | freestanding implementation need not provide . | However, the actual conformance specification in clause 4 | only exempts freestanding implementations from features | specified in the library clause and making complex a keyword | is specified here in the language clause. We need to decide | what we really want to require and make the wording clear | one way or the other. 6.1.3.1, Paragraph 1, Page 47 The 0x and 0X prefixes are used in multiple places, it might simplify the grammar to factor them out into their own nonterminal. Clause 7 There are no synopses for the float and long double versions of the math routines and there are a number of synopses that basically duplicate or refer to other synopses. We should consider allowing multiple synopses for a family of functions with a single description like the Unix man pages have traditionally done. | 7.4 | Much of is appropriate for freestanding | implementations, but not all of it. My suggestion is to | move the conversion functions to and | with the other conversion functions, move the printf/scanf | SC22/WG14 N804 21 macros to (yes, I know that's adding a bunch of | names to a very popular header, but I don't like any of the | alternatives I've heard so far any better), and move the | rest to and require freestanding implementations | to support it. (Changing the name allows implementations | that currently support to continue to provide | it with the existing semantics.) | 7.7.11.2, Paragraph 2, Page 242 It is not clear what the last line (``a call to the nan function is unspecified'') is supposed to mean; is it just | the returned value that's unspecified or is the behavior | completely unspecified? Can such an implementation not | provide the function at all? Can calling the function crash | the program? 7.11.2.1, Paragraph 3, Page 268 It is not clear when the raise function is permitted to fail; is it only for an invalid signal number or are there other conditions? 7.13.5.2, Paragraph 4, Page 283 It is not clear what happens if stream is a null pointer and a write error occurs on one of the streams being flushed. | 7.13.5.3, Page 283 | It has been pointed out that a call like: | fopen("bar", "r") results in undefined behavior since the string literals | might not be distinct and thus do not satisfy the | requirements for restrict-qualified pointers. There doesn't | seem to be much benefit in making the filename and mode | parameters restrict-qualified, so I suggest removing the | qualification. (Also freopen.) | Alternatively (or additionally), we may want to try to | revise the formal definition of restrict to allow aliasing | under limited circumstances (such as read-only usage), but | I'm afraid that's starting down the slippery slope toward | noalias. 7.14.3.4, Paragraph 3, Page 334 The comparison described in the last sentence results in undefined behavior if the object has moved. | 7.3.1 and 7.18.2.1, Pages 185-189 and 372-377 | 22 SC22/WG14 N804 Many of these functions provide very little guidance as to their intended semantics, particularly with respect to the | additional locale-specific characters they accept. It seems like we should say a bit more than we currently do. Annex F There are no entries for ilogb, scalbln, llrint, llround, or nextafterx. We should say something about them, just so it doesn't look like an oversight. | Annex I | There is a new version of ISO TR 10176; the table needs to | be updated (and I suggest removing the leading dashes). The | new specification includes extended digits and special | characters; while it seems reasonable to allow these in | identifiers, it seems like a good idea to disallow an | extended digit as the initial character (that would allow an | implementation to extend the syntax for numeric constants to | include the extended digit characters). I suggest changing | the last sentence of 6.1.2, paragraph 2, page 34 to: | The first character must be a nondigit character; it shall not be a universal character name designating a digit. (also in K.2). | K.2, Page 535, Item 4 | The first character of an identifier can't be a digit, the syntax doesn't allow it. | K.2, Page 540, Item 10 | This isn't undefined behavior. I think the situation that this is supposed to be describing is the one in DR #017, | Question 23: When a macro expansion ends with the name of a | function-like macro and the first token of the remaining | source-file tokens is a (, and that macro expansion ends | with the name of the first macro and the first token of the | remaining source-file tokens is again a (, it is not clear | whether that is a nested replacement or not and thus it | might be replaced and it might not. It is undefined | behavior to depend on one or the other. | I have no idea how to express this succinctly. -- Larry Jones