Stream IO returns wrong file position

[xin_xu]

Hello,

I am using stream io in my fortran code. There is one behavior that I don't understand. The following is a test code shows my confusion. I am using visual studio 2008 and the latest intel fortran compiler. The code is compiled with 4 byte integers.

!=========================
program main

integer :: uf=10, location
integer :: a = 3, b = 4, c = 5, d = 6
integer :: x1, x2, x3, x4

open(unit = uf, file='test.dat', access='stream', form='unformatted', status = 'replace', action='readwrite')

write(unit = uf, pos = 1) a
inquire(unit = uf, pos = location) ! location = 5, OK
read(unit=uf, pos=1) a
inquire(unit=uf, pos=location) ! location = 5, OK

!
! At this point, location = 5. Everything looks ok.

write(unit=uf, pos=location) b ! write b to 'location', which is 5.
inquire(unit=uf, pos=location)
print *, location ! output: 5 How can this be? I thought this should be 9, which is 5 + 4

! Anyway, write an integer to the default pos ( I thought the default pos would be 5
! because the above inquire function said so, and therefore, 'c' would overwrite 'b'.).
write(unit=uf ) c
inquire(unit=uf, pos=location)
print *, location ! output: 9 which is 5 + 4.

! write antoher integer
write(unit=uf ) d
inquire(unit=uf, pos=location)
print *, location ! output 13 which is 9 + 4.

read(unit=uf, pos=1) x1
read(unit=uf) x2
read(unit=uf) x3
read(unit=uf) x4 ! This read passed, there are indeed 4 integers written to the file

print *, x1, x2, x3, x4 ! output: 3 4 5 6 ! why? I thought the output will be 3 5 6

close(uf)
end program
!=========================

Thanks in advance for help!

Regards,
Xin

[Steven_L_Intel1]

Very interesting. It's the READ after the initial WRITE that is creating the confusion - while the WRITEs are doing what you ask, the INQUIRE is getting the position wrong because of the READ. If I remove that READ, then everything works right. Escalated as issue DPD200168946 .

[xin_xu]

Thanks Steve!

Agreed. I have prevously guessed that there are separate file position values for read and write. But it does not seems a valide guess.

Anyway, hope it will be resolved soon.

Regards,
Xin

[Steven_L_Intel1]

This has been fixed for a future version. The library was not properly keeping track of the position for reporting purposes.

[xin_xu]

Thanks very much for the info!

Regards,
Xin