To: J3 J3/18-104 From: Malcolm Cohen Subject: Editor's report for 18-007 Date: 2017 December 30 1. Introduction This is the editor's report. 2. Unauthorised editorial changes [22:12] 3.143.1, definition of "atomic subroutine", append cross-reference "(16.5)" (Atomic subroutines) to defn. {It is convenient to be able to jump straight to this description.} [478:5-8] 17.11.58 IEEE_SUPPORT_STANDARD, p5, Case(i) replace all double underscores with single ones. {Wrong typesetting.} 3. Rejected suggested editorial change [549:27] C.2.3 Generic type-bound procedures, This line is "GENERIC :: OPERATOR(+) => rat_plus_rat, rat_plus_i, i_plus_rat" [550:10] Function statement is "ELEMENTAL TYPE(rational) FUNCTION rat_plus(a,b) RESULT(r)" COMMENT: "I believe rat_plus should be rat_plus_rat here." RESPONSE: No, the GENERIC statement in a type definition takes type-bound procedure names, and the type-bound procedure definition says "rat_plus_rat => rat_plus". So text is correct as is, would be wrong if changed. 4. Papers from PL22.3 meeting 214 17-216r1. [281:17-19] - There is no "13.5.7.1", the paper does not give the subclause name, but the correct reference appears to be 13.7.5.1, unluckily named "Overview"; luckily there is no conflict but this could be improved sometime (I also note that "are" in p1 should be "can be"). Done. 17-217r1. Done. 17-219. Done. 17-230. Done. 17-191. [120:20+] Omitted the BNF ref "(R863)" as it is unnecessary. Done. 17-197r2. Done. 17-208r1. [530:10+] Did as is, but I note that in this (and others), it is possible for the statement to contain more than one team/event/lock variable, so use of the syntax term might be considered more appropriate. OTOH I would hope that no-one would consider such a nonsensical reading. (Any statement that has a variable designator or expression can have an unlimited number of team variables, viz "variables of type TEAM_TYPE", e.g. as actual arguments to function references.) Done. 17-212. Done. 17-218. Done. 17-221r1. Done. 17-224r1. Done. 17-227r1. Done. 17-228. Done. 17-231r1. Done. 17-232 (recommended edit). Done. 17-233. [330:16] The edit said to append "A function name declared with an asterisk \si{type-param-value} shall not directly or indirectly invoke itself or any other procedure defined by the subprogram." This has the problem that "function names" cannot invoke anything as they are names, not functions. I toyed briefly with the simple change "function name declared" -> "function whose name is declared" but then I thought that the previous restriction applied to all the procedures defined by a subprogram that defines a function with a * type-param-value (because the whole subprogram is declared RECURSIVE, which was not allowed). As it seems likely that we want to avoid adding a new feature to this obsolescent hack, I appended "If a subprogram defines a function whose name is declared with an asterisk \si{type-param-value}, no procedure defined by the subprogram shall directly or indirectly invoke itself or any other procedure defined by the subprogram." instead. Done. 17-198. Done. 17-199r1. Done. 17-203r1. Done. 17-213r2. Done. 17-240. Done. 17-241r1. Done. 17-242r1. [191:26-28] Additional edit: after "explicitly specified" inserted "by that statement". {Clarifies where the locality needs to be specified.} Done. 17-244 proposal 2. Done. 17-247r1. Done. 17-238r1. Done. 17-248. Done. 17-236r1. Done. 17-239. Since we're calling it an attribute, I made NON_RECURSIVE an attribute as far as the index is concerned. RECURSIVE remains just a keyword. Actually most attributes are indexed only as attributes (the keyword by itself is not an index entry), but NOPASS, and now NON_RECURSIVE, are indexed both as attributes and also as a simple keyword. These should probably be changed to be indexed only as attributes, viz the keyword indexing should be removed. I did not check all the other attributes to see whether they also existed as keyword entries so it might be just those two. I also found a couple of places where NON_RECURSIVE was used without any indexing; I made these into attribute index entries, except for the one in "Executing defined input/output data transfers", which I made a simple hyperlink. Done. 17-237. Singularised the sentence. Done. 17-235. Done. 17-249. Done. 17-194r2. [390:1+] "the result type for GET_TEAM is" -> "the result of GET_TEAM is of type". Actually, this is only a note, but I note that it is not entirely true. CLASS(*),ALLOCATABLE :: x x = GET_TEAM(-1) should do the usual auto-allocation and assignment to X. Done. 17-195r3. [188:31+] Ugh, this note is a Wall Of Text. "Appendix" forsooth! "Appendix C.6.7 supplies an illustration of this." ->"An example of this is in C.6.7." DELETE "In an image selector... in the image selector." as this has virtually NOTHING to do with the CHANGE TEAM construct, is bad style (I would have to rewrite it to make it proper English), and it is explained properly and fully in 9.6 Image selectors anyway (with reasonable style). Done. 17-202r1. [101:25] Inserted comma at the beginning of the appendage, inserted cross-ref "(16.10.2)" at the end thereof. Done. 17-209r1. General: This has resulted in wording which is redundant - we are specifying the ordering twice (once by "delaying" the execution, then again by specifying the segment ordering explicitly). This result is not really satisfactory. Perhaps there should be some definition somewhere of what these synchronisations imply, then we can just say it is a synchronisation (with ref). Or a blah synchronisation. Whatever. Must be better than repeating ourselves repetitively. I will produce a paper to do this. [142:36] "the current team" -> "this team" twice (already used like this in the paragraph). [146:8] Ditto. [188:19-27] REJECT. p5 is about successful execution. p6 is about failed image execution. The new para starts about successful execution and immediately switches topics. The topic switching is only parseable as every unqualified sentence in the paragraph applying ALWAYS, whether it is successful or unsuccessful for whatever reason. Of course if we'd done a single definition of what we mean by synchronisation we'd just reference with a single word and adding to both paras would be trivial. But we didn't do that. Furthermore, Wall Of Text(tm) is not acceptable. Furthermore, wholesale replacement of paragraphs which, as everyone knows, are full of LaTeX markup, is Extremely Unhelpful and liable to induce editing errors. [188:19-27] Instead, added a new paragraph (p6+) with an obvious "if" condition in front of the segment ordering. I could have extracted the "delay" sentence from p5/6 add put that here as well, but I'm going for minimal rewriting as there is a better chance of not making a mistake. [215:8] "the current team" -> "this team" twice. (terminology already used like this in this para). COMMENT: I wonder if the "an active image ... another active image" is too vague. Why does it not say "all active images ... all active images"? Or "each active image ... all other active images"? Remaining comments do not pertain to the edit, but to nearby text. COMMENT: The CHANGE TEAM spec for failed images is wrong. It says there is an implicit synchronisation of the active images: not so, that only happens if the CHANGE TEAM has a STAT= specifier, otherwise error termination is initiated. Unless they all synchronise and then initiate error termination? Seems like a waste of time! COMMENT: The "coarray shall not become (de)allocated on one image unless it is successfully ... on other images" text could be taken as a requirement on the user. Requirements on the processor are usually stated as semantic facts, and a conforming processor is required to implement those semantics (that's what 4.2p2 item (1) says). As I believe these are intended to be requirements on the processor, rewording should be done. Maybe "A coarray is only successfully allocated on an image if it is successfully allocated on all active images of this team." or "A coarray is either successfully allocated on all active images of this team or on none of them." or even "The processor shall ensure that a coarray is only successfully allocated on an image if it is successfully allocated on all active images of this team." (the last one uses phrasing we do, very rarely, that what is stated as a requirement applies to the processor not the user). Done. 17-205. [45:22] I am not convinced that a cross-reference to the very next subclause is particularly useful, but I left it in anyway. Done. 17-210r1. No edit, so done. 17-211r2. [500:23] Did not insert the additional full stop specified by the edit. "array element number" -> "subscript order value" (that's what we call it - the words "array element number" do not appear anywhere in the standard). Done. 17-214r2. [507:24+] Inserted after the NOTE, which is talking about para 2. COMMENT: [506:35-36] Should "data pointer object" not be "data pointer"? Done. 17-243r1. COMMENT: I hope this has no unintended technical effect! And what on earth is a "transfer statement"? EXTRA EDIT: [532:28] 19.6.7, Variable definition context, item (6), "an IOSTAT=, SIZE=, or IOMSG=" -> "a SIZE= or IOMSG=", because IOSTAT= is now covered by item (9). Done. 17-245r1. Done. 17-246r1. Done. 17-215r1. No edit so done. 17-185r1. [518:1] Applied to [518:7] as noted in meeting discussion. Done. 17-222. Done. 17-223. Done. 17-225. Done. 17-226r2. Done. 17-229. EXTRA EDITS: [263:5] 12.11.2 Error conditions and the ERR= specifier, p2, (2), "error occurs" -> "error condition occurs". [369:33] 16.9.46 CO_BROADCAST, heading, space before "(". [370:13] 16.9.47 CO_MAX, heading, space before "(". [370:35] 16.9.48 CO_MIN, space before "(". [384:10] 16.9.77 FAILED_IMAGES, heading, insert space before "(". [432:11] 16.9.183 STOPPED_IMAGES, heading, space before "(". [435:1] 16.9.189 TEAM_NUMBER, space before "(". [536:23] Annex A, "error occurs" -> "error condition occurs". Done. 17-253r1. Done. 17-196r2. Done. 17-250r2. [xx] after "TEAM_TYPE" insert "from the intrinsic module ISO_FORTRAN_ENV", "may have" -> "can have", singularised and completely rewrote final clause. [75:2] Not sure why you think 18.2 is a better xref than 18.3.3, but I did the change anyway. [133:11] Inserted the necessary comma otherwise the "if" applied only to TEAM_TYPE rendering all C_PTR/C_FUNPTR component usage invalid! [141:28] Inserted the necessary comma otherwise it prohibited all use of a C_PTR or C_FUNPTR source-expr! EXTRA EDIT: [172: NOTE 10.41] "variable of type" -> "variable of declared type" (constraints cannot constrain the dynamic type), "is not permitted to" -> "cannot" (simplify wording), "as an intrinsic assignment for a component in a derived-type assignment" ->"for a component in a derived-type intrinsic assignment" (simplify wording). COMMENT: The referenced constraint in this NOTE, C915, probably also ought to say "declared type" not just "type" (it's the only plausible interpretation, but people have invented implausible readings in the past!). [215:12-] REJECT. This suggested new NOTE contains a normative recommendation. Making a recommendation is a Very Bad Idea anyway, as it does not detract from the semantics in any way. Either it is impossible (or non-conformant) to use a team value from another image, or it is possible and conformant so to do, and if so it needs to be implemented not harangued. [532:9] Inserted extra comma after "same image" to improve readability. Done. 17-252. [449:21] "default IEEE exception handling" ->"default ISO/IEC/IEEE 60559:2011 exception handling" (correct reference to the IEEE standard). Done. 5. Additional unauthorised changes for IEEE conformance. [453:10-11] "copysign" -> "copySign", delete "scalb,", "logb" -> "logB", delete "nextafter,", "unordered" -> "compareQuietUnordered", delete "IEEE_SCALB,", delete "IEEE_NEXT_AFTER,". {IEEE standard has different functions from the deletions, and differently-named ones for the renamings.} 6. Changes to prepare for first draft Format changed to DIS, "Fortran 2015" changed to "Fortran 2018", new WG5 document number. 7. Additional changes and overfull hbox review Reinstated paragraph numbers accidentally disabled in previous version. Reinstated hyperlink colouring with a very dark blue to be unobtrusive. Front matter: Overfull \hbox (4.44443pt too wide) in paragraph at lines 18--53 {This is for the ISO format front page. By eye, there is nothing wrong.} Overfull \hbox (6.79999pt too wide) in paragraph at lines 108--109 {This is the PDF disclaimer. By eye, there is nothing wrong.} Overfull \hbox (10.13332pt too wide) in paragraph at lines 130--136 {This is the ISO copyright info. By eye, there is nothing wrong.} Introduction: Overfull \hbox (6.24548pt too wide) in paragraph at lines 102--117 [intro] Bullet "Intrinsic procedures and modules:", swapped the first two sentences "In references to..." and "In a reference to". {Confirmed that the Overfull warning disappears, and the text looks ok.} Clause 10: Overfull \hbox (3.12904pt too wide) in paragraph at lines 1496--1501 {Confirmed that this intrusion of COMMAND_ARGUMENT_COUNT into the right margin is quite visible.} [168:11-13] 10.1.12 Constant expression, p1, item (6), Reword more verbosely to push the line-break point deeper into COMMAND_ARGUMENT_COUNT: "a transformational standard intrinsic function other than" ->"a standard intrinsic function that is transformational, other than" {Confirmed that the Overfull warning disappears, and the text looks ok.} Clause 12: Overfull \hbox (2.7319pt too wide) in paragraph at lines 1376--1379 {Confirmed that this intrusion of "PROCESSOR_-" into the right margin is visible, though not terrible. Adjusted the wording to be the same as in the OPEN statement, where the problem does not occur.} [238:23] 12.6.2.13 ROUND= specifier in a data transfer statement, After "shall evaluate to" insert "one of". {Confirmed that the Overfull warning disappears, and the text looks ok.} Clause 13: [276] Overfull \vbox (14.45317pt too high) has occurred while \output is active {This is a vertical space issue, so needs to wait until later, but while looking at it I noticed that there was bad capitalisation in NOTE 13.12} [277:1+4] 13.7.2.3.4 EN editing, NOTE 13.12, "Output field Using" -> "Output field using". Clause 13: Overfull \hbox (12.2847pt too wide) in paragraph at lines 2402--2402 {This is very noticeable indeed.} [376:36-37] 16.9.59 DATE_AND_TIME, p3 Arguments, element (4) of VALUES, "time difference with respect to [UTC]" ->"time difference from [UTC]". {Confirmed that the Overfull warning disappears, and the text looks ok.} Overfull \hbox (12.90495pt too wide) in paragraph at lines 2508--2511 {This is very noticeable indeed. I could not think of a simple rewording to fix it without introducing stylistic inconsistencies, so...} [378:17] 16.9.63 DOT_PRODUCT, p5 Result Value, Case (ii), Insert hyphenation point into "VECTOR_B" after "VECT". {Confirmed that the Overfull warning disappears, and the text looks ok.} Overfull \hbox (10.2712pt too wide) in paragraph at lines 5009--5010 {Confirmed that this is noticeable.} [412:9] 16.9.137 MOVE_ALLOC, p7, last bullet, Insert hyphenation point into "STAT_STOPPED_IMAGE" after 1st "P". {Confirmed that the Overfull warning disappears, and the text looks ok.} Overfull \hbox (6.68788pt too wide) in paragraph at lines 7383--498 {Confirmed that this is noticeable, but not completely terrible. As no simple rewording makes an improvement...} [446:2-4] 16.10.2.33 Uniqueness of named constant values, p1 Turn this into a table (without caption or heading), introduced by "The values of these named constants shall be distinct:". {This is unusual typesetting, but ok I think. Alternatively we could just say "The values of the named constants in the module that begin with IOSTAT_ or STAT_ shall be distinct from each other.".} Clause 18: Overfull \hbox (20.57307pt too wide) in paragraph at lines 44--46 {Confirmed that this was very noticeable.} [483:30] Insert hyphenation point into C_INT_LEAST64_T before "64". {This reduces the overfull hbox to 3.07307pt, which is close enough.} [488] Overfull \hbox (5.97508pt too wide) in paragraph at lines 463--464 {This is the middle subheading of Table 18.2: it seems perfectly fine.} [492] Overfull \hbox (1.10333pt too wide) in paragraph at lines 741--742 {Yes this is overfull, but 1.1pt is not noticeable.} Overfull \hbox (15.91588pt too wide) in alignment at lines 1086--1091 {Confirmed that Table 18.5 is very noticeably too wide.} [499-500] Adjust Table 18.5: ISO_Fortran_binding.h macros for error codes so that it is within the text area. Annex A, page 540, Overfull \hbox (13.43715pt too wide) in paragraph at lines 216--217 This is visible, reworded: [540:11-12] bullet beginning "the conditions under which IEEE_DIVIDE...", "involving non-ISO/IEC/IEEE 60559:2011 floating-point data" ->"involving floating-point data that do not conform to ISO/IEC/IEEE 60559:2011". {Confirmed the Overfull warning disappears, and the text looks ok.} 8. Widow and orphan review From here, all page/line references are to the draft with all preceding changes made. They might be somewhat adrift from 17-007r2 and the DIS. Widow/orphan correction is usually done by adjusting the page length. Special macros are used to that these changes can be easily identified and removed before a future revision. Also note that within a clause, all orphan/widow commentary after the first depends on the first (because adjustment always moves things between pages). Changes to any adjustment will require re-processing of the clause. [W: 27-28] In the middle of NOTE 4.1, the last line on p27 is the first line of a sentence. Shortened the page to force that sentence onto the next page. [O: 31-32] 4.3.5 Fortran 95 compatibility, two lines of paragraph 1 appear at the bottom of page 31 and a single half-line on page 32. Lengthened page 31 to include the whole of paragraph 1. [O: 35-36] 5.1 High level syntax, R1420 has two lines at the bottom of page 35 and only one line at the top of page 36. Lengthened page 35 to include the whole of R1420. [O:40-41] 5.3.4 Program execution, paragraph 3 has two lines at the bottom of page 40, and only one line at the top of page 41. Lengthened page 40. [O:47-48] 5.5.7 Companion processors, paragraph 2 has two lines at the bottom of page 47 and only a short line at the top of page 48. Lengthened page 47. [O:59-60] 7.3.2.2 TYPE type specifier, paragraph 2 has five lines at the bottom of page 59 and only one line at the top of page 48. Lengthened page 59. [W:60-61] 7.3.2.3 CLASS type specifier, paragraph 7 has only one line at the bottom of page 60 and lots at the top of page 61. Shortened page 60. [O:70-71] 7.5.2.2 Accessibility, NOTE 7.16 has most at the bottom of page 70 and only one line at the top of page 71. Lengthened page 70. [OW:74-75] 7.5.4.1 Component definition statement, C749 has one line at the bottom of page 74 and one line at the top of page 75. Shortened page 74 (text on 74 was approx 0.5mm longer than 75). [O:77-78] 7.5.4.6 Default initialization for components, R743 has two lines at the bottom of page 77 and one at the top of page 78. Lengthened page 77. [O:78-79] Same subclause, NOTE 7.32 has many lines at the bottom of page 78 and one line at the top of page 79. Slightly lengthened page 78, and deleted some vertical space inside the note. Also indented the code samples from the text as it looks better. [O:79-80] Same subclause, NOTE 7.36 has many lines at the bottom of page 79 and one line at the top of page 80. Reduced some of the vertical space etc. Also indented all the examples in this set as they were not consistent, and indenting makes them easier to read. [O:80-81] Same subclause, NOTE 7.44 has its example split across pages. Insert an explicit page break to put all of the NOTE on page 81, this does leave quite a bit of blank space at the bottom of page 80 though. [O:81-82] Same subclause, C775 has one line at the bottom of page 81 and one line at the top of page 82. Lengthened page 81. [82-83] Same subclause, NOTE 7.42 is split across pages 82 and 83; both pages contain substantial parts of the example. Looking carefully at the NOTE, it has nothing to do with the immediately preceding paragraph (unlike NOTEs 7.43 and 7.44), but is a simple type-bound procedure example. Moved it to the end of the subclause (after NOTE 7.44). Also, indented the code in the example. After that, LaTeX wanted to put NOTE 7.43 (now 7.42) on the page after the paragraph it was commenting on, but clearly there was room at the bottom of page 82 for it so I just lengthened page 83. [O:86-87] 7.5.7.3 Type-bound procedure overriding, the last bullet of paragraph 2 appeared at the top of page 87. Lengthened page 86 and squashed the bullet list up a bit (using "itemise" instead of "itemize" to remove the inter-para space). [W:88-89] 7.5.10 Construction of derived-type values, the first line of paragraph 2 appears at the bottom of page 88, and many lines at the top of page 89. Shortened page 88. [89-90] NOTE 7.61 was split across 2 pages. On examination, NOTEs 7.59 and 7.60 do not have anything to do with the immediately preceding paragraph, so I moved these to the end of the subclause, indenting the text within them and adjusting spacing as I went. After that, the first line of paragraph 7 appeared at the bottom of page 89, so I shortened page 89. [W:95-96] 8.2 Type declaration statement, paragraph two has one line at the bottom of page 95 and many at the top of page 96. Shortened page 95. [OW:99-100] Constraint C825 has one line at the bottom of page 99 and one line at the top of page 100. Lengthened page 99. [O:105-106] 8.5.10 INTENT attribute, paragraph one has three lines at the bottom of page 105 and one line at the bottom of page 106. Lengthened page 105. [O:113-114] 8.6.7 DATA statement, C875 has three lines at the bottom of page 113 and one line at the top of page 114. Lengthened page 113. [OW:116-117] 8.6.12 POINTER statement, R854 pointer-decl has one line at the bottom of page 116 and one line at the top of page 117. Lengthened page 116. [O:118-119] 8.7 IMPLICIT statement, paragraph four has many lines at the bottom of page 118 and one line at the top of page 119. Lengthened page 118. [119-120] While looking over these examples, I noticed that NOTE 8.39 has faulty ellipses (two dots instead of three). Corrected. Also improved (more H less V) spacing inside NOTEs 8.38-8.41. [OW:120-121] 8.8 IMPORT statement, C895, one line at the bottom of page 120 and one line at the top of page 121. Lengthened page 120. COMMENT: Not terribly pleased by the slipshod examples and mid-example page breaks for IMPORT, but it's not bad enough to warrant more work. [O:124-125] 8.10.1.3 Equivalence of default character objects, paragraph two has four lines at the bottom of page 124 and one line at the top of page 125. Lengthened page 124. Tidied up NOTE 8.49 while I was there. [129-130] NOTE 9.1 was split horribly here, so I squashed it up totally and lengthened page 129 - it now fits (it never did before). Perhaps just deleting the NOTE would have been a lot easier! [wherever] I suddenly noticed that all references to NOTEs say "Note" instead of "NOTE". Fixed. [O:131-132] NOTE 9.4 has many lines on page 131 and one line on page 132. Adjusted spacing within the NOTE to make it fit. Also modified indentation. [W:136-137] 9.5.4 Simply contiguous array designators, paragraph two last bullet is the last line on page 136 but it has a long sub-list on page 137. Shortened page 136. [O:139-140] NOTE 9.18 has many lines on page 139 and one on page 140. Adjusted spacing and indentation within the NOTE. [O:154-155] 10.1.5.2.1 Interpretation of numeric intrinsic operations, paragraph one has many lines on page 154 and only one word on page 155. Lengthened page 154. [O:159-160] 10.1.5.5.2 Evaluation of relational intrinsic operations, paragraph one has two lines on page 159 and only one word on page 160 ("violated"). Lengthened page 159. [161-162] A NOTE pertaining to page 161 appears entirely on page 162. Adjusted spacing and indentation in NOTE 12.28. [O:163-164] 10.1.10 Conformability rules for elemental operations, paragraph two has two lines on page 163 and one on page 164. Lengthened page 163. [165-166] Adjusted spacing and indentation in NOTE 10.33 and 10.34. [167] Page was one line too long until I adjusted the spacing and indentation in NOTE 10.35. [W:170-171] 10.2.1.4 Defined assignment statement, paragraph two has one line on page 170 and lots on page 171. Adjusted spacing/indentation in NOTE 10.42, also inserted "assignment" between "intrinsic" and "C = D". [O:172-173] C1030 has two lines on page 172 and one line on page 173. Lengthened page 172. [O:175-176] 10.2.3.1 General form of the masked array assignment, paragraph two has two lines on page 175 and one line on 176. Reworked NOTEs 10.47 and 10.48 to make more room. [176-177] Revised NOTEs 10.49 and 10.50 to make more room, and lengthened page 176. Also replaced faulty ellipses with proper ones. [O:185-186] 11.1.5.1 Purpose and form of the CHANGE TEAM construct, paragraph two has three lines on 185 and one line on 186. Lengthened page 185. Noticed that "RETURN statement" in C1111 was not hyperlinked or indexed: did so. [W:193-194] 11.1.7.6 Examples of DO constructs, heading appears on page 193 but the contents are on page 194. Inserted a hard page break before the heading. Noticed that these examples are horribly formatted but did not fix them. [196-197] Bad page break. Revised NOTE 11.20 and 11.21 to remove excess space and insert indentation, and lengthened page 196. [W:197-198] 11.1.9.3 Examples of SELECT CASE constructs, heading is at the bottom of page 197, insert a hard page break. Noticed these examples are not well formatted: adjusted spacing and indentation. [198-199] Five lines of the longish example in NOTE 11.24 go over the page boundary. Deleting the unnecessary CASE DEFAULT in NOTE 11.23 would get 2 lines back, turning the IF-THEN in the same NOTE into a logical IF would get another 2 lines back,then 1 line is within the page length adjustment. I did not do this though. Even though it would have automatically solved the next one... [W:199-200] 11.1.10.1 Purpose and form of the SELECT RANK construct, C1156 has one line at the bottom and three at the top. Shortened page 199. [200-201] Examples of SELECT RANK, these should be NOTEs not ordinary paragraphs. Changed accordingly. Page break is not very good, but at least the whole of the second example is on the same page. [208-209] NOTE 11.40 has one line on a new page. Revised it for spacing and indentation. [209-210] NOTE 11.42 also suffers from bad page breaking. Revised for spacing and indentation. In NOTE 11.43, inserted ellipsis before the "Initial calculation" comment, which otherwise makes little sense, also "! Perform calculation" -> "... ! Perform calculation" (insert ellipsis, delete extra blank). [O:242-243] 12.6.4.5.3 Formatted data transfer, paragraph seven has three lines on page 242 and one word "occurs" on page 243. Lengthened page 242. [243-244] Bad page break two lines into the interface for READ(FORMATTED), but more importantly the interfaces are numbered as paragraphs (but only make sense as part of the preceding sentence). They are also overly indented and formatted too narrowly. Reformatted all of these, joining the first dummy argument to the initial line. They could be made even more compact by putting all the dummy arguments on the first line like a normal person would, but I did not do that. The page break now occurs three lines into the first interface, which is not ideal but is acceptable. [O:254-255] R1231 inquire-spec has lots of lines on page 254 but only one on page 255. Prettified NOTE 12.57 slightly; could get another line if the variable names were changed, but instead just lengthened page 254. [O:277-278] 13.7.2.4 B, O, and Z editing, paragraph five has two lines on page 277 and one line on page 278. Lengthened page 277. Also hyperlinked INT and REAL in p4. [285-286] NOTE 13.32 split badly. Reformatted it to be slightly less bad. Maybe I should have reworded NOTE 13.31 instead, e.g. "All blanks encountered during" -> "All blanks read by"? [305-306] NOTE 15.7 split awkwardly but cannot be much improved without leaving tons of whitespace at the bottom of 305. Revised for spacing and indentation anyway to make it more readable. [306-307] Tidied up NOTE 15.8 to see if I could improve this. Not really, but it's good to have the NOTE tidied up. [309-310] 15.4.3.6 Procedure declaration statement, paragraph seven has two lines on page 309 and one line on page 310. Removed some excess space in NOTE 15.13 but it didn't help enough, so lengthened page 309. [312-313] NOTE 15.17 broken across pages. Revised to improve readability. [OW:317-318] 15.5.2.6 Allocatable dummy variables, paragraph two has one line at the bottom of page 317 and one at the top of 318. Lengthened page 317. [318-319] NOTE 15.29 split badly because of extra leading space. Fixed. [OW:319-320] 15.5.2.9 Actual arguments associated with dummy procedure entities, paragraph 3 has one line on 319 and one on 320. Improved spacing in NOTE 15.30. [322-323] Revised appalling spacing and indentation in NOTE 15.33. Also improved NOTE 15.34 and NOTE 15.35. [325-326] NOTE 15.39 was split badly: revised for spacing and to fix appalling indentation, also deleting the unnecessary colon after "such as". [326] 15.5.5.3 Resolving procedure references to names established to be only specific, paragraph 1, inserted more vertical space before the bullet list (maybe too much but it pushed the 15.6 and 15.6.1 headings onto the next page, which is frankly a good thing. Noticed that NOTE 15.38 and 15.40 are saying identical things, first about intrinsic procedures, secondly external procedures. Quite apart from this being unnecessary, it does seem redundant. [334-335] C1593 has one line on page 335, OTOH it's followed by useless NOTE 15.47 which refers back to C1593 so not much point in moving the last item (number 8) back onto 334. C1593 is useless and misleading because items (4) and (6), not just (5), might require the processor to know whether PRIVATE thingos have a pointer component. Really this is uninteresting stuff so why is it even here. [338-339] 16.3.1 (in 16.3 Bit model) is split very awkwardly across the page boundary, however fixing is not trivial, and there are at least two lines of the paragraph on 339, so left along for now. It might be useful to investigate rewording possibilities or maybe even a hard page break (though this would make a lot of white space). [339-340] 16.4 Numeric models, paragraph two has one line on page 339 and one equation and two lines on page 340. Although it makes quite a bit of whitespace at the bottom of 339, I think it is better to have the whole of paragraph two on page 340. Added a hard page break. COMMENT: Although that improves this, the whole early part of clause 16 is problematically typeset w.r.t. page breaking. Further attention, rewording or shuffling paragraphs/subclauses, would be warranted. [OW:341-342] 16.6 Collective subroutines, paragraph eight has one line on page 341 and one on 342. Lengthened page 341. [O:351-352] 16.9.9 AINT, p3 has one argument on page 351 and one on 352. Lengthened page 351. [357-358] 16.9.24 ATOMIC_FETCH_ADD, argument ATOM has one line on page 357 and three lines on page 358, This is less than ideal, but the obvious simple changes do not improve things due to knock-on on the next page. [362-363] 16.9.38 BGT, paragraph 3 Arguments has its heading only on page 362. Shortened page 362. [W:365-366] 16.9.46 CO_BROADCAST, only the first line of paragraph five Example appears on page 365. Shortened page 365. [O:366-367] 16.9.49 CO_REDUCE, one line of the example goes onto the next page. Lengthened page 366. [370-371] Example for CPU_TIME is poorly broken across pages but it seems there is nothing that can be done that is not worse. [O:377-378] One line of the example for EVENT_QUERY is on page 378. Reduced the inter-paragraph spacing in the example, and lengthened page 377. [W:380-381] 16.9.78 FINDLOC, Result Value Case (ii) has one line on page 380 and several on page 381. Shortened page 380. [W:382-383] 16.9.82 GET_COMMAND, 1st line of example program is on page 383. Shortened page 383. [389-390] 16.9.96 IEOR, page break in Result Value is poor, but fixing would need moving two lines from 389 to 390, so left alone. [W: 390-391] 16.9.98 IMAGE_STATUS, Result Value has one line on page 390 and two on page 391. Shortened page 390. [W:399-400] 16.9.123 MASKR, Arguments heading is at the bottom of page 399; shortened that page. [O:405-406] 16.9.134 MINVAL, most of the arguments are on page 405, but the MASK argument is on page 406. Lengthened page 405. [O:406-407] 16.9.136 MODULO, the A argument is on page 406 but the P argument is on page 407; Lengthened page 406. [W:408-409] 16.9.139 NEAREST, Arguments heading is at the bottom of page 408. Shortened page 408. [W:411-412] 16.9.145 NUM_IMAGES, Arguments heading is at the bottom of page 411. Shortened page 411. [W:413-414] 16.9.148 PARITY, Examples heading is at the bottom of page 413. Shortened page 413. [W:419-420] 16.9.162 REPEAT, Arguments heading is at the bottom of page 419; shortened page 419. [W:424-425] 16.9.173 SHIFTA, Arguments etc. Shortened. [O:427-428] 16.9.181 SPREAD, Examples, has one line on page 428. Lengthened page 427. [W:451-452] 17.11.1 General (under 17.11 Specifications of the procedures; why are these headings so bad?), paragraph two has one line on page 451 and three on page 452. Shortened page 451. [W:453-454] 17.11.6 IEEE_GET_HALTING_MODE, Arguments heading is at the Shortened page 453. The way we do these headings is definitively suboptimal! [O:456-457] 17.11.14 IEEE_IS_NEGATIVE, Restriction has one line at the bottom of page 456 and one at the top of 457. Lengthened page 456. [W:461-462] 17.11.27 IEEE_QUIET_LE, Arguments heading is at the bottom of the page. Shortened page 461. [O:462-463] 17.11.29 IEEE_QUIET_NE, Example has two words on page 463. Lengthened page 462. [467] 17.11.39 IEEE_SET_STATUS, Deleted excessive space in Example. [OW:482-483] 18.2.3.3 C_F_POINTER, Examples, paragraph after case (iii) one line on page 482 and one line (plus code) on page 483. Shortened page 482. [W:502-503] 18.5.5.9 The CFI_setpointer function, Formal Parameters heading is at the bottom of page 502. Shortened page 502 (by a lot). [O:512-513] 19.4 Statement and construct entities, paragraph seven has four lines on page 512 and one word on page 513. Lengthened page 512. [O:514-515] NOTE 19.5 has three lines at the bottom of page 514 and one line at the top of page 515. Lengthened page 514. [OW:524-525] 19.6.5 Events that cause variables to become defined, item (15) has one line on page 524 and one line on page 525. Shortened page 524 as page 525 is a bit short anyway. [W:526-527] 19.6.6 Events that cause variables to become undefined, item (13) has one line on page 526 and two lines on page 527. Shortened page 526. [W:554-555] C.6.3 Examples of DO constructs, Example 3 heading appears at the bottom of page 554. Shortened page 554. [O:556-557] C.6.5 Simple example using events, one line of the example goes on to page 557. Lengthened page 556. [557-558] C.6.7 Accessing coarrays in sibling teams, example program page break suboptimal, but no significant improvement is easy. [O:570-571] C.9.2.1 USE statement and dependent compilation, paragraph two has two lines on page 570 and one line on page 571. Lengthened page 570 (this also fixes 571-572!). [O:576-577] C.9.3.6 Data abstraction, example code in paragraph three has one line on page 577. Deleted the blank line before the END MODULE statement so it fits on page 576. Noticed that the indentation within the module is slightly lacking (not indented relative to the MODULE, CONTAINS, and END MODULE statements), but left that alone. [O:578-579] C.9.4 Modules with submodules, the END MODULE statement is at the top of page 579. Lengthened page 578. [O:579-580] The submodule is too long so goes two lines onto page 580. Widened the comments and deleted a blank line so that it fits. [580-581] Paragraph nine, the first two lines of the example appear at the bottom of page 580; shortened the page greatly (lots of room on page 581). [584-585] C.10.4 Pointers and targets as arguments, paragraph three has two lines at the bottom of page 584 (one line of code) and lots of code on page 585; added a hard page break as there is plenty of room on page 585. [590-591] C.10.6 Rules ensuring unambiguous generics, interface BAD8 is not only badly split across pages, but has an inappropriate paragraph number. Removed the paragraph and excessive space (it is still split but with two lines on the first page instead of only one line). EXTRA EDIT: Paragraph 27 talking about S9A et al is talking about an example that no longer appears in the standard. This was supposed to be deleted by paper 05-245r1. Deleted. [595-596] C.11.3 Collective subroutine examples, last example has two lines going on to page 596. Squashed up the examples a bit, and lengthened page 595. [W:596-597] C.12.2 Example of Fortran calling C, paragraph five has one line on page 596 and the example on page 597. Reading the text I find a misatke "This example show how", -> "This example shows how", and shortened page 596. [604-605] C.12.9 Processing assumed-shape arrays in C, paragraph two has one line of text plus the first line of the example on page 604 and the rest of the example on page 605. Inserted a hard page break. [608-609] The example is badly split, but nothing simple really improves it (other examples nearby also split, but not as badly). [OW:611-612] C.12.14 Mapping of MPI interfaces to Fortran, paragraph two has the C prototype split across pages. Lengthened page 611. [W:612-613] Paragraph six has one line at the bottom of page 612 and the examples on page 613. Shortened page 612. [W:613-614] C.13 Clause 19 notes : Examples of host association, only the subheading of Example 2 is at the bottom of page 613. Shortened page 613. 9. Technical (editorial) fix [N2137 502:36] 18.5.5.5 The CFI_establish function, Formal Parameters, elem_len, at the end "type will be ignored" -> "elem_len will be ignored". ===END===