This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, Fortran] PR57633 - Fix EOL handling with \r in list-directed I/O
- From: Janne Blomqvist <blomqvist dot janne at gmail dot com>
- To: Tobias Burnus <burnus at net-b dot de>
- Cc: gcc patches <gcc-patches at gcc dot gnu dot org>, gfortran <fortran at gcc dot gnu dot org>
- Date: Thu, 20 Jun 2013 13:34:53 +0300
- Subject: Re: [Patch, Fortran] PR57633 - Fix EOL handling with \r in list-directed I/O
- References: <51C2C75F dot 70707 at net-b dot de>
On Thu, Jun 20, 2013 at 12:11 PM, Tobias Burnus <burnus@net-b.de> wrote:
> gfortran failed to correctly read the file
> line1,1,
> line2
> with DOS (\r\n) line endings. As the code already set EOL for "\r",
> finish_list_read didn't call eat_line. Result: The attempt to read "line2"
> actually accessed the last byte of line one, namely "\n", which it regarded
> as zero-sized string.
>
> That's fixed by the patch to next_char.
>
> eat_separator is a separate issue and unrelated to the PR. I also failed to
> create a test case for it. In any case, I regard the following as wrong:
>
> case '\r':
> dtp->u.p.at_eol = 1;
> ...
> if (n != '\n')
> {
> unget_char (dtp, n);
> break;
>
> As the code explicitly does not regard "\r" as EOL in this case, I believe
> EOL shouldn't be set here.
>
> (Recall, Unix (MacOS X, Linux, ...) have '\n' while DOS/Windows has "\r\n".
> While '\r' as line break exists (old Macs, pre MacOS X), gfortran does not
> support formatted I/O with "\r" record markers.)
>
>
> Build and regtested on x86-64-gnu-linux.
> OK for the trunk?
>
> Tobias
Ok, thanks.
--
Janne Blomqvist