I am not a big expert on

Paul_R_4 · ‎08-06-2018

I've run into a problem with an internal READ statement on a string that contains a newline character. The following minimal working example demonstrates the problem:

program main
  use, intrinsic :: ISO_C_BINDING
  integer :: x(2)
  character(len=3, kind=C_CHAR) :: s
  s = '1' // C_NEW_LINE // '2'
  read(s, *) x
  print *, x
end program main

This program should print out the numbers 1 and 2. However, the presence of a newline in the middle of the string causes ifort to choke:

forrtl: severe (59): list-directed I/O syntax error, unit -5, file Internal List-Directed Read

Image PC Routine Line Source

a.out 000000000042E99E Unknown Unknown Unknown

a.out 000000000040A50D Unknown Unknown Unknown

a.out 0000000000408C76 Unknown Unknown Unknown

a.out 0000000000402CE1 Unknown Unknown Unknown

a.out 0000000000402C1E Unknown Unknown Unknown

libc-2.17.so 00007F403F591C05 __libc_start_main Unknown Unknown

a.out 0000000000402B29 Unknown Unknown Unknown

Here's information about my version:

$ ifort --version

ifort (IFORT) 18.0.1 20171018

For what it's worth, this example works fine with gfortran. As far as I can tell, the F2008 standard does not prohibit a newline from being in the middle of the string like this. Is this indeed a compiler bug?

Juergen_R_R · ‎08-06-2018

I am not a big expert on Fortran I/O, but nagfor also chokes on this leading to a runtime error: Invalid input for integer editing. Program terminated by I/O error on internal file. If you ask for iostat, then ifort gives out a positive 59 on my system, and the prints a 0 0 integer array, but does not segfault. If your string is just "1 2" then the iostat value is 0 and ifort reads and prints out the correct integer array.

Steve_Lionel · ‎08-07-2018

A NEW_LINE in a character value used for internal list-directed READ doesn't start a new record. For internal I/O, each element of a character array variable is a record. Maybe gfortran skips over the NEW_LINE, but that's not specified by the standard.

According to the standard, "The characters in one or more list-directed records constitute a sequence of values and value separators." Value separators are commas, slashes or blanks. NEW_LINE is not one of these.

Paul_R_4 · ‎08-08-2018

Thanks Steve for pointing out the relevant snippet from the standard. Out of curiosity (and since you've been involved in the standards committee), do you know why newlines are not acceptable as value separators?

Steve_Lionel · ‎08-08-2018

List-directed input goes back much further than my involvement in Fortran. The standard's only mention of newlines is in the C interoperability section - newline isn't part of the Fortran character set and is platform-dependent. Even the section on stream access refers generically to "record markers" and not any specific binary character value.

To be honest, I'm not sure why you would think it should be a value separator - newline is typically used (on some platforms but not all) as a record marker, and internal files use a different mechanism for separating records.

mecej4 · ‎08-09-2018

I ran a little test program to ascertain which characters were accepted as separators in the context of the kind of I/O described in this thread. The source:

program main
  integer :: x(3),ich,ios
  character(len=5) :: s
  do ich=1,127
     s = '1' // char(ich) // '2 3'
     read(s, *,iostat=ios) x
     if(ios == 0)then
        print 10, ich,ich,x
     endif
  end do
10 format(1x,I4,1x,Z2,2x,3I4)  
end program main

Intel Fortran, Lahey LF95 and NAG showed <TAB>, <SPACE>, ',' and '/' as accepted separators. Gfortran showed, in addition to these, <CR>, <LF> and ';' as valid separators. Silverfrost FTN95 accepted only space, comma and slash.

If portability is valued in your application, only the three separators listed by Steve should be used.

Bug with list-directed I/O?