This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug fortran/57633] I/O: Problem with formatted read: reading CR-LF files (\r\n)


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57633

--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> ---
The problem seems to be

2012    finish_list_read (st_parameter_dt *dtp)
...
2019      if (dtp->u.p.at_eol)
2020        {
2021          dtp->u.p.at_eol = 0;
2022          return;
2023        }
2024
2025      err = eat_line (dtp);

as at_eol == 1.


Draft patch:

The first hunk solves the actual problem of this PR.

The second one handles the case "abc\rdef" where \r is not followed by \n and
does not start a new record. (Note: gfortran does not handle pre-MacOS X line
breaks of the form "\r", only Windows \r\n and Unix (Linux, MacOS X,...) "\n".)
- that's unrelated to this PR.

--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -244,3 +244,3 @@ next_char (st_parameter_dt *dtp)
 done:
-  dtp->u.p.at_eol = (c == '\n' || c == '\r' || c == EOF);
+  dtp->u.p.at_eol = (c == '\n' || c == EOF);
   return c;
@@ -336,3 +336,2 @@ eat_separator (st_parameter_dt *dtp)
     case '\r':
-      dtp->u.p.at_eol = 1;
       if ((n = next_char(dtp)) == EOF)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]