From jkr@jkr.cc.rl.ac.uk Mon Feb 26 17:39:22 2001 Received: from nameserv.rl.ac.uk (nameserv.rl.ac.uk [130.246.135.129]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id RAA11734 for ; Mon, 26 Feb 2001 17:39:21 +0100 (CET) (envelope-from jkr@jkr.cc.rl.ac.uk) Received: from jkr.cc.rl.ac.uk (jkr.cc.rl.ac.uk [130.246.8.20]) by nameserv.rl.ac.uk (8.8.8/8.8.8) with ESMTP id QAA22213 for ; Mon, 26 Feb 2001 16:39:21 GMT Received: (from jkr@localhost) by jkr.cc.rl.ac.uk (8.8.8+Sun/8.8.8) id QAA25548 for SC22WG5@dkuug.dk; Mon, 26 Feb 2001 16:41:11 GMT Date: Mon, 26 Feb 2001 16:41:11 GMT From: John Reid Message-Id: <200102261641.QAA25548@jkr.cc.rl.ac.uk> To: SC22WG5@dkuug.dk Subject: Iterpretation 24 (partial records): Draft response MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Dear WG5, Here is my next draft interpretation response. This is not a new one. It failed its J3 ballot rather spectacularly. The ballot comments are in 00-329 and are appended for your convenience. Mainly, what people wanted was for the text of the standard to be edited, so I have added an edit. Also, there was concern about saying that a partial record that has been written by a Fortran program 'ought' to be readable by a Fortran program, so I have change the answer a bit too. I have also added a pointer to C.6.1.5 which makes the intention rather clear. I would appreciate comments before I send it to J3, preferably to me in private. Cheers, John. .................................................. NUMBER: 000024 TITLE: Termination of a partial record by a CLOSE, BACKSPACE, ENDFILE, or REWIND statement KEYWORDS: DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: Suppose a partial record has been written as a result of a nonadvancing WRITE. If the file is closed, or a BACKSPACE, ENDFILE, or REWIND statement is performed on the file, must the partial record be terminated? ANSWER: After a nonadvancing WRITE there is always a current record in a file. Existing descriptions of file closure and of the BACKSPACE, ENDFILE and REWIND statements define subsequent operations on the file. Further clarification in the BACKSPACE, ENDFILE and REWIND cases is provided in C.6.1.5 [321:7-11]. The standard does not have the concept of 'terminating' a partial record - the external representation of any file written by Fortran is processor dependent, including the means of determining record boundaries. In the circumstance described, a 'partial' record that has been written by a Fortran program must be readable by a Fortran program. Therefore, on a processor that uses line-feed characters to terminate records, either (i) the processor should emit a terminating line-feed in the situation described, or (ii) the processor should contain the capability to read an 'unterminated' partial record at the end of the file. An edit is provided to make the intention clear. EDIT: Page 136. At the end of the last paragraph of subclause 9.2.1.3.1 [136:33] add If a nonadvancing output statement leaves a file positioned within the current record and no further output statement is executed for the file before it is closed or a BACKSPACE, ENDFILE, or REWIND statement is executed for it, the current record becomes the last record even if it is empty. SUBMITTED BY: Robert Corbett HISTORY: 98-155 m145 Submitted (part 2) WG5/N1410 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Failed J3 letter ballot ........................................................ OLD VERSION AND J3 BALLOT COMMENTS ON IT NUMBER: 000024 TITLE: Termination of a partial record by a CLOSE, BACKSPACE, ENDFILE, or REWIND statement KEYWORDS: DEFECT TYPE: STATUS: J3 consideration in progress QUESTION: Suppose a partial record has been written as a result of a nonadvancing WRITE. If the file is closed, or a BACKSPACE, ENDFILE, or REWIND statement is performed on the file, must the partial record be terminated? ANSWER: After a nonadvancing WRITE there is always a current record in a file. Existing descriptions of file closure and of the BACKSPACE, ENDFILE and REWIND statements define subsequent operations on the file. The standard does not have the concept of 'terminating' a partial record - the external representation of any file written by Fortran is processor dependent, including the means of determining record boundaries. However, a 'partial' record that has been written by a Fortran program ought to be readable by a Fortran program. Therefore, on a processor that uses line-feed characters to terminate records, either (i) the processor should emit a terminating line-feed in the situation described, or (ii) the processor should contain the capability to read an 'unterminated' partial record at the end of the file. EDIT: SUBMITTED BY: Robert Corbett HISTORY: 98-155 m145 Submitted (part 2) WG5/N1410 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Failed J3 letter ballot ---------------------------------------------------------------------- RichB's NO vote on 000024 I agree with Dick Hendrickson/Henry/... that the text of the standard should be altered to explicitly require the partial record to be considered to be a complete record. Malcolm's NO vote on 000024 I concur with the other comments that further specification would be helpful. Craig's NO vote on 000024 I generally agree with the comments of Van Snyder and Dick Hendrickson. I beleive that the proper solution is to add text saying what the processor is required to do if an I/O operation is terminated by something other than an I/O statement with ADVANCE="YES". We should ensure that the standard requires that anything written by a non-advancing WRITE statement ends up in the file REGARDLESS of what happens later. DickH's NO vote on 000024 The proposed answer says in part "However, a 'partial' record that has been written by a Fortran program ought to be readable by a Fortran ^^^^^ program." Nothing in the standard says this! It sounds like a darn good idea, but I don't see how we can deduce it from what is said in REWIND, etc. I think we need to add text something like "execution of this statement on a file which is in the midst of a nonadvancing I/O operation acts as if an advancing I/O operation with a null list was performed just prior to the execution of the statement" to CLOSE, REWIND, ENDFILE, and BACKSPACE. Alternatively we should add general text saying just what the processor is REQUIRED to do when a nonadvancing I/O is "terminated" by something other than an I/O with advance="YES". Things like divide by zero and allocation failure also "terminate" nonadvancing I/O. Ought a subsequent program be able to read those records? Kurt's NO vote on 000024 Minor nit: At a minimum, the "EDIT:" header should either be removed or filled in with "None." I believe I agree with the thrust of this interpretation, but I am unhappy with the justification given. I agree that the standard does not have the concept of 'terminating' a record. It seems to me that the nonadvancing WRITE has conceptually already created a record, but left the file positioned within that record, rather than after it, so additional data may be transferred into that record. The hole in the standard appears to be that it does not state what happens if you attempt to write an endfile record when the file is positioned within a record rather than between two records. I see three obvious possibilities: 1) The endfile record overwrites the current record. 2) The endfile record is written following the current record. 3) Such an attempt is invalid. I have been unable to identify text in the standard to support one of these options over the others. [As a matter of personal preference, I find 1) unacceptable, and I prefer 2) to 3).] If option 2) is chosen, I agree that, for example, a processor could either write NL to the file to maintain the discipline that text records are terminated by NL characters or not write NL and treat the record as being terminated by the end of file. In either case, what was written by that Fortran program would be readable by another Fortran program. [Last minute addition -- Larry Meadows' example illustrates the fact that the convention of terminating a record by the end of file without NL is problematic if the record has zero length.] At this point, it appears to me that this item needs an edit to clarify what should occur when a file is positioned within a record and an endfile record it to be written. Larry's YES comment on 000024 The answer given for item 000024 is misleading for one special case. Consider the program PROGRAM TEST OPEN (10, FILE='XXX') WRITE (10, '()', ADVANCE='NO') ENDFILE (10) END In this case, there must be some indication that a record was written. Since in this case the partial record contains no characters, there must be some indication that a formatted record has been written. Having the capability to read unterminated records is not sufficient for this example. [Bob Corbett] Van's YES comment on 000024 I agree with the spirit of the interpretation, but the wording troubles me. I think the question Corbett is trying to ask is whether the processor has the option to discard part of a record that it may have in a buffer if an advancing WRITE has not occurred prior to closing a file, or doing a BACKSPACE, ENDFILE, or REWIND operation on it. The answer should make it clear that anything written ends up in the file, even if the last WRITE was a nondavancing WRITE. The "terminating a record" question was not, in my opinion, the real question. Jon's NO vote on 000024 Annex C for informative notes contains Section C.6.1.5 Nonadvancing Input/output(9.2.1.3.1) which states the intentions of the developers of the nonadvancing feature: If the last data transfer statement was WRITE and the file is currently positioned within a record, the file will be positioned implicitly after the current record before an ENDFILE record is written to the file, that is, a REWIND, BACKSPACE, or ENDFILE statement following a nonadvancing WRITE statement causes the file to be positioned at the end of the current output record before the endfile record is written to the file. Given this intent, the positioning of the file at the end of the current record is assumed for BACKSPACE, REWIND, ENDFILE, and CLOSE statements after a nonadvancing WRITE statement. To Robert Corbett from Joanne Brixius: The statement from section C states that the file will be positioned implicitly after the current record before an ENDFILE record is written to the file. This means that the program in the Larry Meadows email with the small case: ------------------------------------------begin inclusion > > -C- --- 000024 Termination of a partial record > by a CLOSE, BACKSPACE, ENDFILE, > or REWIND statement The answer given for item 000024 is misleading for one special case. Consider the program PROGRAM TEST OPEN (10, FILE='XXX') WRITE (10, '()', ADVANCE='NO') ENDFILE (10) END In this case, there must be some indication that a record was written. Since in this case the partial record contains no characters, there must be some indication that a formatted record has been written. Having the capability to read unterminated records is not sufficient for this example. [Bob Corbett] --------------------------------------------end inclusion will actually cause an empty record to be completed on output. The Cray implementation creates an empty record in file XXX for the WRITE(10..) followed by the ENDFILE(10). Given the comments, I assumed that there was a question about where the file was positioned and what happened to the file before the ENDFILE, REWIND, BACKSPACE, or CLOSE. Henry's NO vote on 000024 We agree with Dick Hendrickson that the text of the standard should be altered to explicitly require the partial record to be considered to be a complete record. We'd also like to see the behaviour in cases like that described by Larry Meadows need to be made clear. We also feel the implementation-specific details discussed in the response do not really belong there.