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: <CAA-ihx_SR7sb9+Tq_Ok+VM9FbjPLp9Lvk8a+bXf94oj13MTeWg@mail.gmail.com>
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>
X-Mailer: VM undefined under 21.5  (beta32) "habanero" b0d40183ac79 XEmacs
 Lucid (x86_64-unknown-linux)
Date: Sat, 20 Jul 2013 17:20:25 +0900
Message-ID: <87fvv9r6ba.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

Rugxulo writes:

 > (It's not really my decision, so this is just an opinion.) Sure, fine,
 > go ahead and patch it. But I still think it's sloppy on their end
 > (Lua, et al.) to use such a broken idiom.

I don't understand what's "broken" about it.  I would assume that

    ifp = fopen(infile, "r"); ofp = fopen(outfile, "w");

produces an unwritable and an unreadable file respectively, otherwise
why bother with the "rw" modes?  And in fact that appears to be the
case, in DOS as in POSIX systems.  Why wouldn't ferror tell you that
you've got a bad fp in that case?

The *standards* may be "broken" in not defining this case precisely,
of course.  Here's the problem:

 > But there's no reason to be too stubborn if actual code relies on
 > it.

What do you propose that "actual code" rely on, if the operating
system considers this an error but ferror() doesn't?  If you are
attempting an operation on an fp where it's defined to fail, you've
got a real problem, which should be reported.  But as far as I can see
all 4 cases (not EOF and not ERR, EOF and not ERR, not EOF and ERR,
EOF and ERR) are possible.  Why make it obscure to figure out which is
the case?