[Bug libfortran/59727] New: reading from character string returns end of file

[Bug libfortran/59727] New: reading from character string returns end of file

[dms35 at cornell dot edu]

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

            Bug ID: 59727
           Summary: reading from character string returns end of file
           Product: gcc
           Version: 4.6.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libfortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dms35 at cornell dot edu

Created attachment 31779
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31779&action=edit
test program showing end-of-file on reading from a string

I read a line from a file into a character variable (which has room for more
characters than are in the line). When the first character contains a * flag, I
then read some numbers, in free format, from the string. This worked fine with
earlier versions of gfortran, but with version 4.6.2, the read fails with an
"end of file" message. I can get it to work by adding an EOL to the end of the
string, but seems to me that this should not be necessary. A very small program
showing the behavior is attached.

[Bug libfortran/59727] [4.7/4.8/4.9 Regression] reading from character string returns end of file

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
      Known to work|                            |4.5.4
           Keywords|                            |rejects-valid
   Last reconfirmed|                            |2014-01-08
                 CC|                            |jb at gcc dot gnu.org
     Ever confirmed|0                           |1
            Summary|reading from character      |[4.7/4.8/4.9 Regression]
                   |string returns end of file  |reading from character
                   |                            |string returns end of file
      Known to fail|                            |4.6.4, 4.7.3, 4.8.2, 4.9.0

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
This is due to r166180:

Author:    jb
Date:    Tue Nov 2 12:56:38 2010 UTC (3 years, 2 months ago)
Changed paths:    4
Log Message: PR 45629 Remove usage of setjmp/longjmp

[Bug libfortran/59727] [4.7/4.8/4.9 Regression] reading from character string returns end of file

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #1)
> This is due to r166180:
> 
> Author:	jb
> Date:	Tue Nov 2 12:56:38 2010 UTC (3 years, 2 months ago)
> Changed paths:	4
> Log Message: PR 45629 Remove usage of setjmp/longjmp

Note, it may not be a regression, but I need to find time to
go read the standard.  Consider the modified program:

      CHARACTER*40 LINE, msg
      LINE(1:20)=' 12,30.0,10.5,0     '
      print *, '>',trim(line),'<'
      READ (LINE,*,err=10,iomsg=msg) I1,R1,R2,I2
      WRITE (*,1000) I1,R1,R2,I2
   10 print *, i1, r1, r2, i1, msg
 1000 FORMAT (I4,2F10.1,I4)
      END

troutmask:sgk[206] gfc4x -o z p.f && ./z
 > 12,30.0,10.5,0     @Õÿÿÿ<
At line 8 of file p.f
Fortran runtime error: End of file

After the assignment to line(1:20), I don't remember if the
standard requires the remaining space to be blank padded.
The problem is that line(21:40) contains whatever is in memory
as demonstrated by the 'print *,...' statement.  I suspect that
we are missing a eat_line() (or whatever the function is named).

One workaround is to set line='' as the first line of code.
>From gcc-bugs-return-439714-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jan 09 00:29:21 2014
Return-Path: <gcc-bugs-return-439714-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 30422 invoked by alias); 9 Jan 2014 00:29:21 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 30383 invoked by uid 48); 9 Jan 2014 00:29:18 -0000
From: "kargl at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libfortran/59727] [4.7/4.8/4.9 Regression] reading from character string returns end of file
Date: Thu, 09 Jan 2014 00:29:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libfortran
X-Bugzilla-Version: 4.6.2
X-Bugzilla-Keywords: rejects-valid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: kargl at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-59727-4-7nVte8lz1X@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59727-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59727-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-01/txt/msg00856.txt.bz2
Content-length: 141

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY727

--- Comment #3 from kargl at gcc dot gnu.org ---
Note this might be related to PR 59700.

[Bug libfortran/59727] [4.7/4.8/4.9 Regression] reading from character string returns end of file

[dms35 at cornell dot edu]

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

--- Comment #5 from Marian Szebenyi <dms35 at cornell dot edu> ---
(In reply to Jerry DeLisle from comment #4)

Seems to me that once the 4 items requested in the read statement have been
satisfied, i.e. 4 properly-delimited items have been found, what is in the rest
of the string should be irrelevant. With this interpretation, the original code
is perfectly valid.

> The following also runs without error.
> 
> My initial thought is that the content of the string after the 20th char is
> undefined and this results in undefined behavior.  As Steve notes, any junk
> can be in there.
> 
> C TEST READING FROM CHARACTER STRING
>       CHARACTER*144 LINE
> C
>       LINE(1:20)=' 12,30.0,10.5,0     '
> C CRASHES AT RUN-TIME UNLESS THE FOLLOWING LINE IS UNCOMMENTED
> C     LINE(30:30)=CHAR(10)
>       READ (LINE(1:20),*) I1,R1,R2,I2
>       WRITE (*,1000) I1,R1,R2,I2
>  1000 FORMAT (I4,2F10.2,I4)
>       END
> 
> I think the original code is invalid because of the undefined string. Prior
> to the patch mentioned in Comment 1, the run-time library did not "read" or
> interpret an EOF character.
> 
> Tracing the error shows that the error occurs in finish_list_read where we
> do an eat_line which gives the error.  If we want to accept the behavior, we
> probably could have a unique eat_line for internal character units.
> 
> I am not sure we want to accept the behavior yet and I don't think we should
> call it a regression.

[Bug libfortran/59727] [4.7/4.8/4.9 Regression] reading from character string returns end of file

[jvdelisle at gcc dot gnu.org]

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

--- Comment #6 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
(In reply to Marian Szebenyi from comment #5)
> (In reply to Jerry DeLisle from comment #4)
> 
> Seems to me that once the 4 items requested in the read statement have been
> satisfied, i.e. 4 properly-delimited items have been found, what is in the
> rest of the string should be irrelevant. With this interpretation, the
> original code is perfectly valid.
> 
This is why we need to check the standard. Normally when reading from a line,
you move to the end of the line after the last valid value to prepare for the
next read.  This is a requirement for file I/O.

In your case, the end of the record is not at at the end of the 20 bytes of
substring that you give to the read statement.

READ (LINE(1:20),*) I1,R1,R2,I2 is more correct in that it does not pass
undefined content to the READ.

I am not saying you are wrong, I am just saying that the string expression LINE
in its entirety as specified would be classified by the Fortran standards as
undefined since it has not been fully initialized.  Therefore, by the Standard,
it is invalid code.

However, this does not mean we would not want to accept it as an extension and
do something differently.  Usually in cases like this, we dialog a bit about it
in bugzilla here or on the gfortran list and we will also see what other
compilers do with this case and then we will decide what to do.

[Bug libfortran/59727] [4.7/4.8/4.9 Regression] reading from character string returns end of file

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4
   Target Milestone|---                         |4.7.4

[Bug libfortran/59727] [4.7/4.8/4.9 Regression] reading from character string returns end of file

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |jvdelisle at gcc dot gnu.org

--- Comment #7 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
I will have a look at it this one as well.

[Bug libfortran/59727] [4.7/4.8/4.9 Regression] reading from character string returns end of file

[jvdelisle at gcc dot gnu.org]

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

--- Comment #8 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
The patch committed as shown in comment #42 of pr38199 appears to fix this one
incidentally. Regarding comment 5, I am still not sure the code is valid, but I
do agree there is no reason to give an error either.  I will be looking at a
few other issues related to this and will close the PR when we are confident
there is not something else lurking here.  See also PR58324

[Bug libfortran/59727] [4.7/4.8/4.9 Regression] reading from character string returns end of file

[jvdelisle at gcc dot gnu.org]

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

--- Comment #9 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
(In reply to Jerry DeLisle from comment #8)
> The patch committed as shown in comment #42 of pr38199 appears to fix this
> one incidentally. Regarding comment 5, I am still not sure the code is
> valid, but I do agree there is no reason to give an error either.  I will be
> looking at a few other issues related to this and will close the PR when we
> are confident there is not something else lurking here.  See also PR58324

I can confirm this bug is fixed on trunk.  I also have a patch posted for
PR58324 which demonstrates they were really one in the same bug related to how
and when eat_line was being used.

[Bug libfortran/59727] [4.7/4.8/4.9 Regression] reading from character string returns end of file

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #10 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Although the code now work as expected by the reporter (after r208528 for
trunk, r208595 for 4.8, and r208599), I agree that the code is invalid. Closing
as such.