J3/99-159R1 Date: 9 June 1999 To: J3 From: R. Maine Subject: Recursive I/O The first edit in paper 99-135 mentions the possibility that a DTIO routine might close the file being read. I believe that this points out a problem that is really much broader and is better fixed in another place (though the fix involves few words). We not only don't want the file in question closed, we don't want it reopened, repositioned (except via data transfer), or otherwise "messed with". And we don't want any other external file operated on either. In f95, we disallowed all forms of recursive I/O by the prohibition against I/O in a function referenced in an input/output statement. This was the only way that recursive I/O could have occurred in f95. The intention in f2k was to allow only two specific forms of recursive I/O - recursive data transfer statements in DTIO, plus recursive internal I/O more generally. But the restrictions in 9.10 fail to prohibit the case of recursive I/O statements that are not data transfer statements. I believe this was accidental and that this is where the fix should be. Grep reveals that the term "recursive data transfer statement" is defined and used only in 9.10. Thus I propose the following edits to 99-007r1, all in 9.10. [228:9] "A data transfer" -> "An input/output" [228:10,11,14,2nd case on 9] "data transfer" -> "input/output" (4 times) (but leave the one on line 12 and the one straddling 11-12 alone). [229:11-13] Delete the para. This is now redundant; it is just one specific case of the reworded restriction at [228:11-13].