From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17841 invoked by alias); 15 Jul 2014 21:44:02 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 17670 invoked by uid 48); 15 Jul 2014 21:43:55 -0000 From: "manfred99 at gmx dot ch" To: gcc-bugs@gcc.gnu.org Subject: [Bug libfortran/59513] [4.8/4.9/4.10 Regression] Fortran runtime error: Sequential READ or WRITE not allowed after EOF marker, possibly use REWIND or BACKSPACE Date: Tue, 15 Jul 2014 21:44: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.7.2 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: manfred99 at gmx dot ch X-Bugzilla-Status: NEW X-Bugzilla-Priority: P5 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.8.4 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: 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-07/txt/msg01028.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59513 Manfred Schwarb changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |manfred99 at gmx dot ch --- Comment #22 from Manfred Schwarb --- I just encountered the same issue, with some convoluted legacy code. The scheme seems to be the same: READ(lun,END=100) buffer 100 WRITE(lun,*) "whatever" As the used code definitely was used in practice, mainly before the year 2000, I guess that older compiler supported this. And yes, the BACKSPACE() trick works. However, common sense suggest that with END= we are at the end of the file. This sounds a bit like the old joke, where you have a room with 5 people, you are taking 6 out, so someone has to go in for the room to be empty. Beyond EOF simply does not exist. Jerry, concerning your cited standard: "If the file contains an endfile record" suggests that there is some special marker in the file to be read/written. In this example, we are doing some formatted IO to a plain text file, there are no special markers. Do I miss something? What does/should ftell() report in such a case? That we are one character beyond EOF?