From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22508 invoked by alias); 31 Mar 2007 16:28:20 -0000 Received: (qmail 22411 invoked by uid 48); 31 Mar 2007 16:28:06 -0000 Date: Sat, 31 Mar 2007 16:28:00 -0000 Message-ID: <20070331162806.22410.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug fortran/31366] Last record truncated for read after short write, direct access file In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "jvdelisle at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2007-03/txt/msg02853.txt.bz2 ------- Comment #8 from jvdelisle at gcc dot gnu dot org 2007-03-31 17:28 ------- Thomas, thanks for c.l.f query. From the response so far: >> > > 9.5.3.4.1 "On output to a file connected for unformatted direct access, > the output list shall not specify more values than can fit > into the record. If the file is connected for direct access > and the values specified by the output list do not fill the > record, the remainder of the record is undefined." > > The value of I is at least undefined. > It would seem then that variable i in the test case is undefined and should not be used for anything. That makes this problem moot. Ifort accepts the code and does nothing. Lets adjust the test case a bit: PROGRAM test CHARACTER(LEN=8) :: as_written, as_read character(1) :: byte as_written = "12345678" OPEN (76, ACCESS="DIRECT", RECL=12) WRITE(76, REC=1) as_written WRITE(76, REC=2) as_written READ(76, REC=1) as_read, byte, byte, byte, byte READ(76, REC=2) as_read, byte, byte, byte, byte PRINT *, "as_written = ", as_written, " as_read = ", as_read print *, byte CLOSE(76) END PROGRAM test In this case, the reading of record 2 should be at least consistent with reading of record 1. In the case of 1, byte is set to whatever default value the OS gives in the last four bytes in the record, in my case zero. In case 2, I get an error. I think we should not give an error and consider possibly not assigning byte a value for the last record (it remains undefined so it doe not matter) or pad the last record with '\0' on the write similar to what is done for record 1, and just reading that padding in. The padding would yield more consistent results, though strictly not required since that portion of the record is undefined. However, there is a performance penalty doing that padding. So I am leaning to just not giving the error and let the variable remain untouched. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31366