From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-456390-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 11990 invoked by alias); 15 Jul 2014 14:58:16 -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 11862 invoked by uid 55); 15 Jul 2014 14:58:07 -0000
From: "sgk at troutmask dot apl.washington.edu" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/61632] Memory corruption on error when writing formatted data
Date: Tue, 15 Jul 2014 14:58:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.8.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: sgk at troutmask dot apl.washington.edu
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: jvdelisle at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61632-4-2TrXT2nbyF@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61632-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61632-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-07/txt/msg00981.txt.bz2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61632

--- Comment #17 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Tue, Jul 15, 2014 at 09:08:44AM +0000, dominiq at lps dot ens.fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61632
> 
> --- Comment #15 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> > Its sort of like Steve said earlier.  The coder is choosing to ignore an
> > error condition so anything gfortran does is valid.  In this case the
> > output got writen to buffer before the error occurred.  You are bypassing
> > all of the normal error handling when you do this. The buffer got flushed.
> >
> > Its not worth the time to change any of it really.
> >
> > The program should exit, its invalid.
> 
> Well, I disagree with this interpretation: I did not find anywhere in the
> standard that the variable set by iostat has to be used.

I did not say that iostat had to be used.  However, one can find 
things like:

9.10.1     Error conditions and the ERR= specifier

If an error condition occurs during execution of an input/output
statement, the position of the file becomes indeterminate.

9.2.3.3   File position after data transfer

If an error condition (9.10) occurred, the position of the file
is indeterminate.

If one explicitly uses IOSTAT= in an IO statement, it may be
prudent to actually check its value.