Re: Problem reading unformated file and using ERR=

[Tobias Burnus <burnus at net-b dot de>]

Chris Talley wrote:
> I've been helping a co-worker attempt to compile and run a legacy CFD
> code using gfortran from the 4.2-20061031 (prerelease) build. When
> reading an unformatted sequential file, the CFD code uses a statement
> as follows:
>
>       READ(1,ERR=10,END=100) I,J,K
>
> The original intent of the ERR specifier was to jump to label 10 if an
> end-of-record occurred before all the requested data was read. This
> works as intended using the NAG F95 compiler; however, using gfortran
> the code jumps to label 100. If the END=100 specifier is remove,
> gfortran gives a runtime end-of-file error. Is this a bug or am I
> doing something wrong?
What the ERR and END should do is described in the Fortran 2003
standard, section 9.10 and in Fortran 95, 9.4.1.5f.
(See http://gcc.gnu.org/wiki/GFortranStandards). I find the former more
readable and quote therefore from F2003:

[End-of-file condition]
"If an end-of-file condition occurs during execution of an input/output
statement that contains neither an END= specifier nor an IOSTAT=
specifier, execution of the program is terminated."
"If an END= specifier appears, execution continues with the statement
labeled by the label in the END= specifier."

Thus giving a run-time error for the end-of-file condition with the END=
specifier removed is correct.
Similarly, if an end-of-file condition occures, using END=10 is also
correct.

(Note that end-of-record has a special meaning in Fortran and uses the
EOR= specifier; but EOR= can only be used with form="formatted" and
advance="no".)


But there is nonetheless a bug in gfortran, which is revealed by your
program:

> Below is a test program and its resulting output.
[...]
>       WRITE(1) I
>       WRITE(1) I, J, K
>       WRITE(1) I, J, K
[...]
>       READ(1,ERR=10) I,J,K

The file contains 3 record with one, three and three integer values.
If one tries to read three integers from the file there is no chance
that one can hit the end-of-file condition; there are only three
possibilities to hit such a condition, none of which is met:

"(1) When an endfile record is encountered during the reading of a file
connected for sequential access."
"(2) When an attempt is made to read a record 1 beyond the end of an
internal file."
"(3) When an attempt is made to read beyond the end of a stream file."

The problem is that gfortran tries to read three numbers of the first
record which contains only one integer; the other compilers
automatically advance to the next record and read the first value of the
first record and the first and second value of the second record.

Thanks for finding the bug.
I filled it as PR30009 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30009)

Tobias