UDDTIO: can the compiler issue a more meaningful error code during defined read of an internal file unit?

[FortranFan]

Fortran 2008 standard  (WD 1539-1 J3 10-007r1 24th November 2010)  document says in section 9.6.4.8.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?

Thanks,

[Steven_L_Intel1]

This looks familiar - I think it's one we're already working on. I have asked the developers to look at it.

[Steven_L_Intel1]

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." (9.6.2.4)

"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)

[FortranFan]

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. ..

Steve,

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.

[Steven_L_Intel1]

Yes, it's a different problem in that the fix made for the other thread needed to be made in an additional place that was missed.

[Steven_L_Intel1]

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.

[FortranFan]

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.