Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
118 Views

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
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
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
Highlighted
Valued Contributor I
118 Views

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. 

 

0 Kudos
Highlighted
Black Belt Retired Employee
118 Views

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.

0 Kudos
Highlighted
Beginner
118 Views

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?

0 Kudos
Highlighted
Black Belt Retired Employee
118 Views

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.

0 Kudos
Highlighted
Black Belt
118 Views

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.

0 Kudos