When reading a "dos" file, gfortran returns two records for each line in the file: the real record and a null one. In other words it is treating the carriage return as a newline instead of the pair carriage return/newline as the newline. Here is an example: integer ios character buf*(50) c open(10,file='dos',iostat=ios) print *,' open ios ',ios 1000 read(10,'(a)',iostat=ios) buf if(ios .ne.0) go to 9000 print '(a,a,a)',' read <',buf,'>' go to 1000 c 9000 end
*** Bug 24918 has been marked as a duplicate of this bug. ***
First can you try 4.0.2 or a snapshot of 4.0.3? Second can you attach the dos file?
Subject: Re: GFORTRAN input and carriage returns On Thu, 17 Nov 2005, pinskia at gcc dot gnu dot org wrote: > > > ------- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-17 20:13 ------- > First can you try 4.0.2 or a snapshot of 4.0.3? Second can you attach the dos > file? > > > -- > > pinskia at gcc dot gnu dot org changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |pinskia at gcc dot gnu dot > | |org > > Sorry, but there was no good way to do that with the form.
Created attachment 10268 [details] dos
Confirmed on the mainline.
This is near stuff I am working on so I will work it.
(In reply to comment #6) > This is near stuff I am working on so I will work it. This is amazing because I thought I add it fixed some time ago now. I will look into it too in the train tonight ;-)
(In reply to comment #3) > Subject: Re: GFORTRAN input and carriage returns > > On Thu, 17 Nov 2005, pinskia at gcc dot gnu dot org wrote: > > > > > > > ------- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-17 20:13 ------- > > First can you try 4.0.2 or a snapshot of 4.0.3? Second can you attach the dos > > file? Tried yesterday's snapshot of 4.1 and it still does not work. > > > > > > -- > > > > pinskia at gcc dot gnu dot org changed: > > > > What |Removed |Added > > ---------------------------------------------------------------------------- > > CC| |pinskia at gcc dot gnu dot > > | |org > > > > > > Sorry, but there was no good way to do that with the form. >
(In reply to comment #8) > Tried yesterday's snapshot of 4.1 and it still does not work. OK, I'm on it. Looks like someone forgot about CRLF systems :) I'll try to submit a first patch tomorrow...
(In reply to comment #9) > (In reply to comment #8) > > Tried yesterday's snapshot of 4.1 and it still does not work. > > OK, I'm on it. Looks like someone forgot about CRLF systems :) > > I'll try to submit a first patch tomorrow... > The following changes in transfer.c appear to fix the problem in Linux: 157c157 < char *base, *p, *q; --- > char *base, *p, *q, last; 173a174 > last = 0; 197c198 < if (readlen < 1 || *q == '\n' || *q == '\r') --- > if (readlen < 1 || *q == '\n' ) 215a217,219 > if ( last == '\r') { > *length = n-1; > } else { 216a221 > } 222a228 > last = *q; Ray
(In reply to comment #10) > The following changes in transfer.c appear to fix the problem in Linux: Confirming this patch, I have something similar in my own tree. But there are some other problems with CRLF and I'll try to submit a full patch soon (a few days at most) to fix them all. Forcing HAVE_CRLF in config.h and running the testsuite appears to be a very good way to find those :)
Subject: Re: GFORTRAN input and carriage returns fxcoudert at gcc dot gnu dot org wrote: > ------- Comment #11 from fxcoudert at gcc dot gnu dot org 2005-11-21 14:02 ------- > (In reply to comment #10) > >>The following changes in transfer.c appear to fix the problem in Linux: > > > Confirming this patch, I have something similar in my own tree. But there are > some other problems with CRLF and I'll try to submit a full patch soon (a few > days at most) to fix them all. Forcing HAVE_CRLF in config.h and running the > testsuite appears to be a very good way to find those :) > > Tres bien!
(In reply to comment #10) > The following changes in transfer.c appear to fix the problem in Linux Well, this patch is actually not OK, since it causes regression in the handling of EOR (like eor_handling_3.f90 and eor_handling_5.f90 from the testsuite). I'm still working on something, but wanted to note somewhere (just in case) that this patch is not OK.
Created attachment 10325 [details] Almost complete patch for handling CRLF correctly Attached patch corrects the problem reported here as well as most other problems related to CRLF. There is still a slight issue with the handling of T format descriptors. When this is resolved, I'll submit the patch properly.
Complete patch submitted for review.
Subject: Bug 24919 Author: fxcoudert Date: Sun Nov 27 11:42:46 2005 New Revision: 107563 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107563 Log: PR libfortran/24919 * io/list_read.c (eat_separator, finish_separator, read_character): Handle CRLF separators correctly during reads. (nml_query): Use the HAVE_CRLF macro to print adequate newlines. * io/io.h (st_parameter_dt): Add comment about the possible values for sf_seen_eor. * io/unix.c (tempfile, regular_file): HAVE_CRLF doesn't imply that O_BINARY is defined, so we add that condition. (stream_at_bof): Fix typo in comment. * io/transfer.c (read_sf): Handle correctly CRLF, setting sf_seen_eor value to 2 instead of 1. (formatted_transfer_scalar): Use the sf_seen_eor value to handle CRLF the right way. * io/write.c (nml_write_obj, namelist_write): Use CRLF as newline when HAVE_CRLF is defined. * gfortran.dg/ftell_1.f90: Modify testcase so that it doesn't fail on CRLF platforms. * gfortran.dg/ftell_2.f90: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/ftell_1.f90 trunk/gcc/testsuite/gfortran.dg/ftell_2.f90 trunk/libgfortran/ChangeLog trunk/libgfortran/io/io.h trunk/libgfortran/io/list_read.c trunk/libgfortran/io/transfer.c trunk/libgfortran/io/unix.c trunk/libgfortran/io/write.c
Will wait a bit before backporting to 4.1.
Subject: Bug 24919 Author: fxcoudert Date: Fri Dec 2 15:35:47 2005 New Revision: 107895 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107895 Log: PR libfortran/24919 * io/list_read.c (eat_separator, finish_separator, read_character): Handle CRLF separators correctly during reads. (nml_query): Use the HAVE_CRLF macro to print adequate newlines. * io/io.h (st_parameter_dt): Add comment about the possible values for sf_seen_eor. * io/unix.c (tempfile, regular_file): HAVE_CRLF doesn't imply that O_BINARY is defined, so we add that condition. (stream_at_bof): Fix typo in comment. * io/transfer.c (read_sf): Handle correctly CRLF, setting sf_seen_eor value to 2 instead of 1. (formatted_transfer_scalar): Use the sf_seen_eor value to handle CRLF the right way. * io/write.c (nml_write_obj, namelist_write): Use CRLF as newline when HAVE_CRLF is defined. Modified: branches/gcc-4_1-branch/libgfortran/ChangeLog branches/gcc-4_1-branch/libgfortran/io/io.h branches/gcc-4_1-branch/libgfortran/io/list_read.c branches/gcc-4_1-branch/libgfortran/io/transfer.c branches/gcc-4_1-branch/libgfortran/io/unix.c branches/gcc-4_1-branch/libgfortran/io/write.c
Backported to 4.1. Will not fix on 4.0 since 4.1.0 will be released soon and mingw does not intend to use gcc-4.0.x