This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/57633] I/O: Problem with formatted read: reading CR-LF files (\r\n)
- From: "burnus at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 20 Jun 2013 08:44:51 +0000
- Subject: [Bug fortran/57633] I/O: Problem with formatted read: reading CR-LF files (\r\n)
- Auto-submitted: auto-generated
- References: <bug-57633-4 at http dot gcc dot gnu dot org/bugzilla/>
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)