J3/03-214r1 Date: 20 August 2003 To: J3 From: Dick Hendrickson Subject: Report II from subgroup Chapter 8 onwards: N1557 Re: WG5/N1557 J3 responses to WG5 paper N1557. Many comments are processed in different papers. These papers are noted here, but the details of the WG5 comments and responses are deleted here. Note that the J3 papers cited may have subsequent revisions and pointers to additional papers. ISO/IEC JTC1/SC22/WG5 N1557 Report II from subgroup Chapter 8 onwards Paper N1545 See J3/03-207 Paper N1547 See J3/03-208R1 N1524 Page and line numbers in paper N1524 refer to 02-007r3. WG5 used these line numbers as well as those from the present draft (03-007). To avoid confusion, these J3 responses will only use the 03-007 page and line numbers paper 03-104r2 See J3/03-208R1 Note that 208R1 only reaffirms a decision to make no edits paper 03-108r3 179:18 Replace "The size ... the value of" by "The number of bits in a file storage unit is given by" paper 03-113r3 See J3/03-225 and 03/240 paper 03-118r3 No edits or action paper 03-119r1 See J3/03-243 paper 03-120r1 See J3/03-243 paper 03-121r1 223:18-19. WG5 rejects this unnecessary change. paper 03-126 14.9.21 now refers to 14.10.23. WG5 agrees; proposed edits: 383:11-13 Replace "Here, ... values" -> "Here, support is as defined in the first paragraph of 14.8". 370:29-30: "available" -> "supported" paper 03-125r1 85:10 Delete "(if any)" 85:12 Delete "(if any)" paper 03-130r2 225:30 now refers to 230:6 and 17. WG5 agrees; proposed edit: 230:17: "The" -> "An". 230:17: "for" -> "that is". "otherwises". WG5 agrees; proposed edits 230:28 Before "otherwise" change comma to semicolon. 230:33 Change "Otherwise" to "For an internal value that is neither an IEEE Infinity nor a NaN". 231:10 Change "Otherwise" to "For an internal value that is neither an IEEE Infinity nor a NaN". 232:2 Change "Otherwise" to "For an internal value that is neither an IEEE Infinity nor a NaN". 232:24 Change "Otherwise" to "For an internal value that is neither an IEEE Infinity nor a NaN". paper 03-131r1 WG5 agrees; proposed edit to simplify table: 371:38-372:22 Change the 12 right hand table entries from "Inquire whether the processor supports XXX" to "Are IEEE exceptions supported?" "Is IEEE halting control supported?" "Is IEEE arithmetic supported?" "Are IEEE denormal numbers supported?" "Is IEEE divide supported?" "Is IEEE infinity supported?" "Is IEEE formatting supported?" "Are IEEE NaNs supported?" "Is IEEE rounding supported?" "Is IEEE square root supported?" "Are all IEEE facilities supported?" "Is IEEE underflow supported?" J3 recognizes that these are brief descriptions, but, combined with the function name, they should allow a reasonably naive user to locate the correct function. paper 03-138r1 See J3/03-225 paper 03-154r3 24:17 WG5 agrees; proposed edit: 24:17 Replace "relevant standard" by "ISO/IEC 646:1991 (International Reference Version) and ISO/IEC 10646-1:2000 UCS-4, respectively" 40:13+ now refers to 42:12-13. WG5 agrees; proposed edits: (Note that 03-208R1 also makes edits in this area) 42:12-13 Replace by: "The collating sequence for the ASCII character type is as defined by ISO/IEC 646:1991 (International Reference Version); this collating sequence is called the <> in this standard." 42:13+ Replace NOTE 4.16 by: "The intrinsic functions ACHAR (13.7.2) and IACHAR (13.7.45) provide conversion between characters and corresponding integer values according to the ASCII collating sequence." 143:12 Delete "the" twice 193:14 now refers to 195:25-196:1. Rejected by WG5, because it was intended this way (default character type might contain characters not suitable for an ASCII internal file, while an ISO 10646 internal file is suited for all characters). 195:21-196:1 WG5 recommends to leave "contain" as is; "item" is a term well defined in this section. 224:14+ now refers to 228:11+. The conversion mentioned here applies to all subsequent data editing, so it is in the right place; WG5 recommends to do nothing. "Conversion" issue: The conversion mentioned in 10.6 is concerned with the conversion caused by data edit descriptors. WG5 recommends to do nothing. 210:12+ now refers to 214:17+. WG5 does not understand the problem; this issue does not arise with formatted files. 351:14-25+ Delete from "The following example..." through to and including NOTE 13.18 Remind the editor to look at note 4.14 which has a similar typesetting problem. paper 03-155r1 308:7. after "X < 0," insert " then" 308:8. insert a comma between "negative real zero" and "and". 331:10. after "of X is zero, " insert "then " 331:12 insert a comma between "negative real zero" and "and". paper 03-157r1 268:7 now refers to 274:7. WG5 rejects this change. The definition of C character kind type is in 15.1.1; WG5 disagrees with moving it. 405:36 now refers to 418:7. Same issue. No edits paper 03-159r2 351:37-38 WG5 agrees; proposes edit: 351:37-38 Replace "2 ... respectively" with "two integer kinds, 32 with representation method r=2 and q=31, and 64 with representation method r=2 and q=63". paper 03-162r2 110:24-25 now refers to 113:1+. WG5 proposes the following alternative edits: 113:6 Delete "An allocatable variable has a status of <> if it is not allocated.". 113:7 Change "unallocated" to "<>". 113:8 Change "an allocation" to "the allocation". 287:15 now refers to 293:15. WG5 agrees that MOVE_ALLOC is not elemental; it is pure, though. Proposed edit: 293:15 Replace the first sentence with: "The subroutine MOVE_ALLOC and the elemental subroutine MVBITS are pure." [13.5.14+1] now refers to 299:28. WG5 proposes the following: 299:28 Replace "procedures" by "procedure". 299:29 Replace "Transfers" by "Moves". 299:29 Replace "allocatiom" by "allocation". Spelling error 339:24 Replace "Transfers" by "Moves". 339:29 Change "remains" to "becomes". 340:3 Change "such a pointer" to "any pointer associated with FROM on entry". 340:8 Add closing parenthesis to the ALLOCATE statement. WG5 thinks the other parts of 13.7.82 are OK. 404:29+ now refers to 416:29. WG5 agrees that this is wrong. Proposed edit: 416:28-29 Replace by "The allocation transfer procedure (13.7.82) is executed with the pointer associated with the argument FROM and an object without the target attribute associated with the argument TO." paper 03-164r1 See J3/03-225 paper 03-172r1 See J3/03-243