The following fortran code: === begin code === program main
implicit none integer :: iostat, n_chars_read character(len=1) :: buffer(64) = "" open( unit=10, status="old", file="simple_dos.txt" ) do read( unit=10, fmt='(64A)', advance='NO', iostat=iostat, & size=n_chars_read ) buffer print *, ' n_chars_read = ', n_chars_read print *, ' buffer = "', buffer(1:n_chars_read), '"' if( is_iostat_eor(iostat) ) then print *, ' iostat = ', iostat, ' (END-OF-RECORD)' else if( is_iostat_end(iostat) ) then print *, ' iostat = ', iostat, ' (END-OF-FILE)' exit else print *, ' iostat = ', iostat stop 'ERROR' end if print * end do end program main === end code === compiled in a standard way (just "-g" for debugging) cannot read more than one line of a DOS file (which contain "\r\n" at the end of each line). For example, with the DOS file: === begin simple_dos.txt === (\r stands for the <CR> character) a\r b\r c\r === end simple_dos.txt === it produces: kaolin $ ./main n_chars_read = 1 buffer = "a" iostat = -2 (END-OF-RECORD) n_chars_read = 0 buffer = "" iostat = 5008 STOP ERROR When reading the UNIX version of the same file: === begin simple.txt === a b c === end simple.txt === it produces good results: kaolin $ test_get_unit_2.8 n_chars_read = 1 buffer = "a" iostat = -2 (END-OF-RECORD) n_chars_read = 1 buffer = "b" iostat = -2 (END-OF-RECORD) n_chars_read = 1 buffer = "c" iostat = -2 (END-OF-RECORD) n_chars_read = 0 buffer = "" iostat = -1 (END-OF-FILE) ______________________________________________________________ The bug doesn't arise when I replace the character array by an ordinary character string, declared as: character(len=64) :: buffer = "" This bug affects the 4.4.1 release and the 4.5 current beta, not for 4.3.4, so we can considering a regression in 4.4/4.5 Moreover, valgind-3.5.0 detect some uninitialised value on line 245 of libgfortran/io/transfer.c, in the 'read_sf' routine of the 4.4/4.5 release. Comparing this source file for the 4.3/4.4/4.5 versions, I saw that the 'read_sf' has been completely redesigned after 4.3 When writing some information, I'm pretty sure that: *(p + 1) == '\n' (inside the test on the line 245 of the same file) is not the valid way to test the next character, because the pointer p points to only one character, *(p + 1) always returns a NULL char. Unfortunately, I cannot propose a patch. -- Summary: [4.4/4.5 regression] bad iostat when reading DOS file in a character array (non-advancing) Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Edouard dot Canot at irisa dot fr GCC build triplet: i686-linux-gnu GCC host triplet: i686-linux-gnu GCC target triplet: i686-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41328