[Cfp-interest 3023] Re: C23 editorial review draft

Wed Mar 6 14:23:16 PST 2024

FYI, here are the consolidated comments.

My comments have a * prefixing the ones that are CFP related (I didn’t separate them out from the regular C review). Please let me know if I missed anything or if anyone disagrees/has comments.

If I don’t hear back from anyone, I will post these to the WG14 editorial review group (removing the names) by this Friday.

Rajan:

Comment 9: Footnote 45). Change to "Two types *do not have to* be identical..."
     Footnote 52). Change to "type *is not necessary to* be performed..."
     Footnote 69). Change to "thus may convert to different internal formats and values."
     Footnote 215). Change to "do not have to support;"
     Footnote 236). Change to "errno does not have to be"
     Footnote 309). Change to "implementation does not have to provide"
     Footnote 312). Change to "implementation does not need to distinguish"
     Footnote 318). Change to "identifiers do not need to be modifiable"
     Footnote 346). Change to "this does not have to be the same"
     Footnote 387). Change to "and the value does not have to be negative."
Comment 64: 6.7.3.3#20. Change "Now, consider a similar fragment, ..." to "A similar fragment, ..."
Comment 125: *5.1.2.4#13. Change to "of a register can not alter the value."
       *5.1.2.4#13. Change to "load rounds to the precision"
       *5.1.2.4#13. Change to "assignments perform their"
       *5.2.5.3.2#36. Change to "constants could possibly not give".
       6.5.3.6#12. Change to "literal have to be constant".
       6.7.2#20. Change to "specifier can have".
       6.7.13.8.2#3. Change to "definition can for example".
       *6.7.13.8.3#8. Change to "the result can depend on"
       6.10.4.1#17. Change to "can violate the constraint"
       6.10.4.2#7. Change to "violation since an environment that has a CHAR_BIT greater than 24 could possibly not get enough data from the resource."
       6.10.4.2#8. Change to "implementations that could have an".
       7.21.1#5. Change to "Implementations can diagnose".
Comment 185: 5.1.2.5#24. Change to "evaluation can take".
       5.1.2.5#38. Change to "shared memory location possibly will not preserve".
       6.2.6.2#5. Change to "bits could generate".
       *6.4.4.3#12. Change to "rounding can yield"
       6.7.2#19. Change to "can cause constraint".
       6.7.13.8.1#10. Change to "call can be safely".
       6.7.13.8.1#10. Change to "the reordering can, in principle,".
       6.7.13.8.3#4. Change to "attribute can depend".
       7.24.3.4#3. Change to "implementation can ignore".
       7.24.3.4#4. Change to "call could possibly not be passed".
       7.24.3.5#3. Same as 7.24.3.4#3.
       7.24.3.5#4. Same as 7.24.3.4#4.
       *F.5#6. Valid use of "shall". Keep as is unless we have a good alternative ("will"?).
       *F.10.12.1. Change to "that could potentially not be supported".
       *F.10.13.1. Same as F.10.12.1.
       *H.2.4#4. Change to "type could have the same".

Fred:

References to page numbers are printed pages (not PDF pages).

"need not" is still in the document:
 page 43, footnote 45
 page 47, footnote 52
 page 62, footnote 69
 page 191, footnote 215
 page 209, footnote 236
 page 319, footnote 309
 page 323, footnote 312
 page 329, footnote 318
 page 365, footnote 346
 page 415, footnote 387

Clicking on left side table of contents does not work -- goes to page i.

"revision" -> "edition" on pages xiii, 55, 188, 189, 291, 457, 458,
459, 625, 674.

Do not like that the page footers no longer have the clause number.
But, it was due to **-135.

It is not clear to me when "family" should be in an index entry:
 Page 689: canonicalize has family, while cacos does not.
 Page 708, index entry "strfromd 358" should be  "strfromdN 358"
 Page 708, index entry "strtod 360, 361" should be  "strtodN 360, 361"
 Page 708, index entry "wcstod 435, 436" should be  "wcstodN 435, 436"

 Index is missing "family" for
 "...dN function"
 "...dNx function"
 "...fN function"
 "...fNx function"
 eg, ... is acos, acosh, and so on to tgamma, trunc
End of "family" issue.

Should there be "strfromencf32" and  "strfromencf64" on page 614?

Jim:

>From reviewing the titling, numbering and referencing of tables in the C23 editorial review draft, I have the following additional comments.

++++++++++++++

5.2.5.3.4 #11, a note, just above Table 5.2. A footnote in the previous draft was turned into this note. The footnote was attached to the last sentence of the paragraph preceding the note. As a note, it’s not clear what “these cases” refers to. Suggest reverting back to the footnote. An alternative fix would be changing the note to: "Although unspecified in ISO/IEC 60559, a preferred quantum exponent of 0 would be a reasonable implementation choice for the cases where the formula is undefined and the function result is finite.”

Table 7.1 and elsewhere. Table headers are not in Bold. Headers in tables in ISO Directives, Part 2, Clause 29 (Tables) are in Bold. I don’t see this stated as a requirement.

(Breaks in Tables H.1 and H.2 noted in previous comments.)

Table H.4 was moved to the wrong place. It should be with the example in H.11 #7.

Table H.4 uses a header style similar to the one that ISO calls incorrect in Example 4 in  https://www.iso.org/sites/directives/current/part2/index.xhtml#_idTextAnchor424<https://www.iso.org/sites/directives/current/part2/index.xhtml#_idTextAnchor424>.

Table numbering skips from H.4 to H.9.

The remaining comments pertain to DIS comment:

**-184

Table titles and numbers

Several tables (typically referred to as “the following table”) don’t have titles or numbers:
6.4.1 #3
6.4.4.5 #3
6.5.16 #10
7.11.2.1, Examples 1 and 2
7.17.6 #1
7.27 Example
Annex E, several
F.3 #20. The title could be “Operation binding — mathematical operations”.
G.5.2 #2, #3.

There are some tables that are not referred to as a table, and that do not have a title or number, e.g.
6.4.4.5 #9
7.27 #12
G.5.3 #2 (like G.5.2 #2, #3 mentioned above)

Table references

7.27 #13 says “indicated in the table in 7.6.2”. Should be “indicated in Table 7.1”. Actually it should be “indicated in Tables 7.1 and 7.2, though that would be a technical change.
In F.10 #10, #11, and #13, Table F.2 is referred to as "the 'Operation binding' table in F.3”, contrary to ISO style which would be just “Table F.2”.
In F.10 #16 the unnumbered table in F.3 #20 is referred to as "the F.3 table of operations recommended by ISO/IEC 60559”. The table should be given a number (noted above) and be referred to by that number.
G.5.2 footnote 449 refers to “the tables”. (Clear enough but doesn’t fit ISO guidelines.)
H.2.2 footnote 452 refers to “the tables”. Should be “Table H.1 and Table H.2”.
H.10 #4 refers to “In 7.6.2, the table of functions affected by constant rounding modes for standard floating types”. Should be "Table 7.1".
H.10 #5 refers to "In 7.6.3, in the table of functions affected by constant rounding modes for decimal floating types”. Should be "Table 7.2".
H.13 Example refers to “the following tables H.9 and H.10” and “the following table H.10”. Should be “Tables H.9 and H.10” and “Table H.10” (no “the following”).
M.1 #1 refers to “this table”. Should be “Table M.1”.
M.1 #2 “in a table” should be “in the table”.

** -002
Ok

**- 016
Ok

**- 024
Ok, except …
Appropriate changes of “negating” to “arithmetically negating” were not made:
6.4.4.3 #12 (3 instances)
7.3.9.4 #2 Change “negating the sign of its imaginary part” to “arithmetically negating its imaginary part”.
Footnote 340
Footnote 405
F.5 #5
J.1 #1 (44)

**- 033
Ok

AT035
Ok (in PDF n3219)

**- 038
Still a hanging paragraph in F.10 (not mentioned in comment). Fixing it would change Annex F subclause numbers for all the math functions. Suggest no change for C23.
Still a hanging paragraph in H.11 (not mentioned in comment).
Otherwise ok for Annexes F, G and H (others not checked).

** -046
Ok

GB1 2- 048
Ok

GB1 1- 049
Ok

GB1 0- 050
Ok

** -068
Ok

** -069
The first change also replaced a semicolon with a period (preceding “Implementations conforming to Annex F have this behavior”). The semicolon made it clearer what “this behavior” refers too. Suggest restoring the semicolon.
Otherwise ok.

GB3 3- 078
Ok

** -085
Ok
H.11.3.2.3, last line, is “See EXAMPLE in H.11.3.3.2.” I believe ISO style would be “See Example in …” or “See the example in …”.

GB5 3- 104
Ok

GB5 4- 105
Ok
There’s a bad line break right after the top line of the 7.6.3 Synopsis box.
There’s a space at the beginning of the 4th line of 7.6.3 #2.

In the end of 7.23.6.2, in Forward references, the 2nd line begins with a comma “,”.

GB6 8- 121
Ok

** -128
Ok

GB7 2- 134
Ok

GB7 9- 142
OK

GB7 6- 143
Ok
The breaks in the tables are awkward. I assume the entire tables won’t fit the page width. Adding a title for the second part of each table would be helpful, e.g. “Table H.1 (continued)”, which is what ISO suggests for tables that must be continued on another page. There’s a lot of space between the two parts of the tables.

GB7 7- 144
Ok

GB1 08- 146
GB1 07- 147
GB1 06- 148
GB1 05- 149
GB1 04- 150
GB1 03- 151
GB1 02- 152
GB1 01- 153
GB1 00- 154
GB9 9- 155
GB8 5- 164
GB8 9- 165
GB8 8- 166
GB8 7- 167
Didn’t check 146 - 167 above, which refer to the Annexes and Annex J.

GB9 2- 175
Ok

GB9 1- 176
Ok regarding comment resolution, but ...
Don’t “TS 18661-n” need to be written as “ISO/IEC TS 18661-n”?
CFP and WG14 work referred to TS 18661-4a, but the “4a” doesn’t appear on any published document. The “a” doesn’t seem necessary because the bullet says “mathematical functions” which points to the feature that was integrated. Suggest omitting the “a”. Also, TS 18661-4 2nd edition is expected to publish at about the same time as C23, which means an undated reference to TS 18661-4 would be wrong (the new one doesn’t include the mathematical functions). Suggest using dated references to the TSes:
ISO/IEC TS 18661-1:2014
ISO/IEC TS 18661-2:2015
ISO/IEC TS 18661-3:2015
ISO/IEC TS 18661-4:2015

**- 189
Ok

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20240306/5d265b80/attachment-0001.htm>