[Bug fortran/31366] Last record truncated for read after short write, direct access file

["jvdelisle at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- 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