X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f
X-Recipient: djgpp-workers AT delorie DOT com
From: "Stephen J. Turnbull" <turnbull AT sk DOT tsukuba DOT ac DOT jp>
To: djgpp-workers AT delorie DOT com
Subject: Re: Set _IOERR if the file stream has been opened in wrong mode.
In-Reply-To: <83r4etxpv5.fsf@gnu.org>
References: <51E5D0C6 DOT 1060404 AT gmx DOT de>
	<83y5951a79 DOT fsf AT gnu DOT org>
	<51E702E0 DOT 3010809 AT gmx DOT de>
	<83fvvc1t0x DOT fsf AT gnu DOT org>
	<8738rcsdik DOT fsf AT uwakimon DOT sk DOT tsukuba DOT ac DOT jp>
	<201307180459 DOT r6I4xWxV010383 AT envy DOT delorie DOT com>
	<51E9D758 DOT 8000209 AT gmx DOT de>
	<CAA-ihx_SR7sb9+Tq_Ok+VM9FbjPLp9Lvk8a+bXf94oj13MTeWg AT mail DOT gmail DOT com>
	<87fvv9r6ba DOT fsf AT uwakimon DOT sk DOT tsukuba DOT ac DOT jp>
	<8361w5zl86 DOT fsf AT gnu DOT org>
	<87a9lhqz60 DOT fsf AT uwakimon DOT sk DOT tsukuba DOT ac DOT jp>
	<83wqolxy5m DOT fsf AT gnu DOT org>
	<878v11qpwa DOT fsf AT uwakimon DOT sk DOT tsukuba DOT ac DOT jp>
	<83r4etxpv5 DOT fsf AT gnu DOT org>
X-Mailer: VM undefined under 21.5  (beta32) "habanero" b0d40183ac79 XEmacs
 Lucid (x86_64-unknown-linux)
Date: Sun, 21 Jul 2013 02:26:26 +0900
Message-ID: <877gglqh19.fsf@uwakimon.sk.tsukuba.ac.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

Eli Zaretskii writes:

 > The issue is something else: whether ferror should return true or
 > false after you try those scenarios.

Yes, I know that.  I'm responding to peripheral issues *you* brought
up, trying to clarify my position that ferror *should* return true in
those scenarios.

Here's what I've already said on that issue:

(1) The standards don't say explicitly, as several people have stated.

(2) A large number of tested OS/libcs all have implemented ferror to
    return true.  (I didn't say that, Juanma did.)

(3) It is plausible that if you requested a read-only file handle,
    it's an error if you try to write to it (because it's a logic
    error -- you should have known better), and vice versa.

(4) It is convenient for ferror to return true in those cases in
    principle (ie, without depending on the consensus in (2)), because
    ferror true implies that is a bad idea to retry the operation.