Fortran 2008 standard (WD 1539-1 J3 10-007r1 24th November 2010) document says in section 126.96.36.199.3 Defined input/output procedures:
Consider the following simple code:
module t_m use, intrinsic :: iso_fortran_env, only : iostat_end, iostat_eor, output_unit implicit none private type, public :: t private character(len=:), allocatable :: m_s contains !private procedure, pass(this), private :: read_t generic :: read(formatted) => read_t end type t contains subroutine read_t(this, lun, iotype, vlist, istat, imsg) ! argument definitions class(t), intent(inout) :: this integer, intent(in) :: lun character(len=*), intent(in) :: iotype integer, intent(in) :: vlist(:) integer, intent(out) :: istat character(len=*), intent(inout) :: imsg !.. Local variables character(len=*), parameter :: sfmt = "(*(g0))" character(len=1) :: c integer :: i i = 0 loop_read: do i = i + 1 read( unit=lun, fmt="(a)", iostat=istat, iomsg=imsg ) c select case ( istat ) case ( 0 ) write( output_unit, fmt=sfmt) "i = ", i, ", c = ", c case ( iostat_end ) write( output_unit, fmt=sfmt) "i = ", i, ", istat = iostat_end" exit loop_read case ( iostat_eor ) write( output_unit, fmt=sfmt) "i = ", i, ", istat = iostat_eor" exit loop_read case default write( output_unit, fmt=sfmt) "i = ", i, ", istat = ", istat exit loop_read end select end do loop_read return end subroutine read_t end module t_m
program p use t_m, only : t implicit none character(len=:), allocatable :: s type(t) :: foo character(len=256) :: imsg integer :: istat s = "Hello" read( unit=s, fmt=*, iostat=istat, iomsg=imsg ) foo if ( istat /= 0 ) then print *, "istat = ", istat print *, imsg end if stop end program p
Upon compilation and executing using Intel Fortran compiler 17 update 1, the output is
i = 1, c = H i = 2, c = e i = 3, c = l i = 4, c = l i = 5, c = o i = 6, istat = 67 istat = 67 User Defined I/O procedure returned error 67, message: input statement requires too much data, unit -5, file Internal List-Directed Read
Is this conformant with the standard?
Note for the same, gfortran issues the error code of iostat_end which appears more meaningful in this context.
Can Intel Fortran development team please review this and follow up as needed?
Yes, it's very similar to https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/618870#comment-1864365 The tracking ID for this issue is DPD200416704.
I think gfortran is incorrect, though - it should be returning an EOR condition, not EOF. Quoting from F2008:
"A formatted child input/output statement is a nonadvancing input/output statement, and any ADVANCE= specifier is ignored." (188.8.131.52)
"An end-of-record condition occurs when a nonadvancing input statement attempts to transfer data from a position beyond the end of the current record, unless the file is a stream file and the current record is at the end of the file (an end-of-file condition occurs instead)." (9.11.1)
Steve Lionel (Intel) wrote:
Yes, it's very similar to https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-fo... The tracking ID for this issue is DPD200416704.
I think gfortran is incorrect, though - it should be returning an EOR condition, not EOF. ..
Thanks. So this issue is similar to those others but still a new one, right? Meaning the tracking ID is a fresh incident? In the link you provide above, your last comment dated 07/29/2016 says, "All of the issues raised in this thread have now been fixed" except for one that was going to be fixed in Update 1. I'm now using compiler 17, update 1.
Re: gfortran, I agree completely - I was also expecting an EOR condition; I only brought it up to indicate the difference in responses. I didn't want to comment any further but rather let the Intel Fortran development team determine the best response.
Also, I passed along the gfortran issue to those developers - they entered Bugzilla https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881 for it, and they noticed that the characters were read wrong as well.
Steve Lionel (Intel) wrote:
Also, I passed along the gfortran issue to those developers .. and they noticed that the characters were read wrong as well.
Thanks, Steve. I had noticed the same with gfortran and was contemplating how best to forward the issue, you saved me time.