gfortran I/O issues.

[Smith-Rowland, Edward M]

All,

I'm sorry, I was using 4.1.2 when I said it worked without err set.
This seems to parse as list-directed regardless.
4.3 and 4.4 do indeed show the error message when err is set and throw a
runtime error when it is not.

Note: In my example I forgot to skip over the error message if no error.
Sorry :o)

Sorry for the noise and thank you for the std clarification.  Fortran is
not my main language.

So I think for standard conforming code we should be using fmt=*.
Otherwise we'll get different results depending.

Ed

-----Original Message-----
From: Tobias Burnus [mailto:burnus@net-b.de] 
Sent: Thursday, January 22, 2009 3:08 PM
To: Smith-Rowland, Edward M
Cc: 3dw4rd@verizon.net; fortran@gcc.gnu.org
Subject: Re: gfortran I/O issues.


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