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:
Here's information about my version:
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.
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?
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.
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.