Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Bug with list-directed I/O?


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       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
Copyright (C) 1985-2017 Intel Corporation.  All rights reserved.
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?
0 Kudos
5 Replies
Valued Contributor I

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. 


Black Belt Retired Employee

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.


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?

Black Belt Retired Employee

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.

Black Belt

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