------- Comment #2 from tkoenig at gcc dot gnu dot org 2006-11-28 22:23 -------
(In reply to comment #0)
> See http://gcc.gnu.org/ml/fortran/2006-11/msg00708.html
> Reported by Chris Talley.
>
> Tested with current 4.3 and also with 4.1.
>
> Testcase, see URL; essential parts of the test case (form="unformatted"):
> WRITE(1) 1
> WRITE(1) 2, 3, 4
> WRITE(1) 5, 6, 7
> REWIND(1)
> READ(1,ERR=10) I,J,K
> The read should read "1" of the first record and then "2" and "3" of the
> second
> record.
I don't think so.
F 2003, 9.5.3.4.1 (Unformatted data transfer):
# On input from a file connected for sequential or direct access,
# the number of file storage units required by the input list shall
# be less than or equal to the number of file storage units in the record.
This is not a constraint, so the burden is on the programmer.
In other words, the program is non-conforming. We are definitely
not required to read past the end of the current record.
> gfortran however reads "1", hits then the end of the record and gives
> an end-of-file error.
End of file is misleading, true. In the "Intel subrecord" patch
(PR 29568), an error condition is raised for this case. I have
Changing keyword to "diagnostic", and assigning to myself.
--
tkoenig at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tkoenig at gcc dot gnu dot
| |org
BugsThisDependsOn| |29568
AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Keywords|wrong-code |diagnostic
Last reconfirmed|2006-11-28 21:49:15 |2006-11-28 22:23:23
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30009
