"read" with implied-doloop

"read" with implied-doloop

Dear Forum,

please consider this small code:

program impldo
implicit none
integer(kind=4) :: i
integer(kind=4),dimension(2) :: a=(/1,2/),b
b=z'ffffffff'
open (7,file='c: mpqqq.bin,form='binary')
write (7) a
rewind (7)
read (7) (a(i),i=1,2)
write (*,'(2i4)') a
read (7) (b(i),i=1,0)
write (*,'(2i4)') b
close (7)
end program impldo

The last read statement causes an "end-of-file"-message. It looks as if the fortran read routine inspects where the file pointer is, before looking at what there is to read. As my implied-doloop means "nothing", I'd expect that the fortran read routine would return to my program without error. Using "iostat" is of no avail, as it would mask true erroneous end-of-file conditions. Why is "reading nothing" not allowed at the end of a file? (Or, am I totally wrong and is something completely different the mater?)

Best regards,

Niels H. Veldhuijzen
Cito, Arnhem, The Netherlands


Kind regards,
Niels H. Veldhuijzen
Zutphen, The Netherlands
7 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

You're misunderstanding a fundamental aspect of Fortran I/O. Fortran is record oriented - the READ reads a record and then (and only then) transfers data from the record. There were no more records, hence the READ gets an EOF - the same would happen if you left the variable list off entirely.

Steve

Steve - Intel Developer Support

Dear Steve,

thank you for your quick reply. I'd like to point out three things.
1) If I exchange the two read statements in my sample program:

read (7) (b(i),i=1,0)
write (*,'(2i4)') b
read (7) (a(i),i=1,2)
write (*,'(2i4)') a

all is well. The first read statement reads "nothing" as it should, and array "a" is read correctly. Why should this behaviour not obtain when the two read statements are in different order?
2) In my sample program, the file is declared as "binary". So there is no record structure, as far as I know. In this case, what do you mean by "record" in your reply, and what is the meaning of the sentence at the bottom of page 10-28: "For data transfer, the file must be positioned so that the record read is an unformatted record or an end-of-file record"?
3) The situation is very unfortunate. In fact, we have to revise all our programs. Sometimes, just by accident, a situation as shown in my sample program might occur (it took us fourteen years to hit upon one). In fact, we are forced to check if the end of file has been reached just before every read statement!

Best regards,
Niels H. Veldhuijzen


Kind regards,
Niels H. Veldhuijzen
Zutphen, The Netherlands

I'd agree with Niels here -- binary sequential read should be "nonadvancing"; read of zero bytes should advance the position for zero bytes. Of course, "BINARY" is CVF extension so it may do as pleased, but the current behaviour simply doesn't feel right.

Jugoslav

Jugoslav
www.xeffort.com

Ah, I had missed that this was form='binary'. I agree that it should be nonadvancing. Which compiler and version is this? Have you reported it to support?

Steve

Steve - Intel Developer Support

Yes, it is a binary file.
No, I did not report this to support, but I shall do this next week.
I'm using CVF6.6B.
Thanks to all of you who reacted to my first message!
- Niels -


Kind regards,
Niels H. Veldhuijzen
Zutphen, The Netherlands

My apologies - I apparently skimmed your initial post even more quickly than I thought.

The issue is, as you stated, what happens when you're currently at the EOF point and do a zero-length BINARY read. Your program already demonstrates that zero-length BINARY reads are non-advancing, but as you surmise, the run-time library is checking the position first before looking at the transfer length.

We agree that this is a bug and I have entered it in our bug tracking system.

Steve

Steve - Intel Developer Support

Leave a Comment

Please sign in to add a comment. Not a member? Join today