From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-440008-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 21576 invoked by alias); 10 Jan 2014 17:55:34 -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
Received: (qmail 21531 invoked by uid 48); 10 Jan 2014 17:55:31 -0000
From: "dms35 at cornell dot edu" <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: Fri, 10 Jan 2014 17:55: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: dms35 at cornell dot edu
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-ZOLHx5dJ5T@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/msg01150.txt.bz2

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.