gfortran I/O issues.

[Tobias Burnus]

Hi Ed,

Smith-Rowland, Edward M wrote:
> I thought the "," was a separator and the read should stop for that
> integer and go on to the next.
>   
I thought that was only for list-directed read. I think someone needs to
check the standard, but I bet it is the case.

 * * *

OK. The Fortran 2003 standard has:

"10.9 List-directed formatting
"List-directed input/output allows data editing according to the type of
the list item instead of by a format specification. It also allows data
to be free-field, that is, separated by commas (or semicolons) or blanks."

Thus for list-directed formatting the "," is indeed the separator. And
one also finds:

"9.5.1.1 FMT= specifier in a data transfer statement
The FMT= specifier supplies a format specification or specifies
list-directed formatting for a formatted input/output statement." [...]
"If format is *, the statement is a list-directed input/output statement."

Unless I have missed something in the standard, you really only get the
"," as separator if you are using  fmt=* . (I personally don't see any
reason for using something else but * (except for backward compatibility
and for some very strangely formatted files), but this is a matter of
taste.)

> I think ifort must treat this as legal (the test case is derived from
> code supplied by a customer of mine who uses ifort).
As written: The program  works with the latest ifort 11 and with sunf95
(Sun Studio 12) and Open64.

> I'll ask what version he uses (probably 10).  Maybe the compiler got stricter?
>   
Well, even with "ifort -stand f95 -warn all" it is accepted - and ifort
11 is the latest. (I'm not sure whether the standard mandates that the
compiler diagnoses such errors.)

> About the extra line in gfortran 4.1/4.2, ifort 11, sunf95 and openf95
> it looks like the string is parsed as three comma delimited integers
> then it prints the results and THEN goes to the error message which
> seems strange in itself.
>   

Well, that is OK: Since there is no "STOP" or similar in the program, it
simply goes on executing the next line ...

> Later gfortrans (4.3, 4.4) will happily do the same parsing and printing
> if the ierr flag is removed.

Hmm, not here. With today's GCC 4.3 and 4.4 branch I _do_ get a run-time
error message.

Tobias