Date: Mon, 1 May 2000 06:25:18 -0400 (EDT)
Message-Id: <200005011025.GAA00121@indy.delorie.com>
From: Eli Zaretskii <eliz AT delorie DOT com>
To: Nate Eldredge <neldredge AT hmc DOT edu>
CC: djgpp-workers AT delorie DOT com, zack AT wolery DOT cumb DOT org, lauras AT softhome DOT net,
        gcc-patches AT gcc DOT gnu DOT org
In-reply-to: <14605.19595.491155.235037@mercury.st.hmc.edu> (message from Nate Eldredge on Mon, 1 May 2000 02:21:15 -0700 (PDT))
Subject: Re: Minor DJGPP fixes
References: <390C769C DOT 812EAB7D AT softhome DOT net>
	<20000501000928 DOT J11780 AT wolery DOT cumb DOT org>
	<200005010837 DOT EAA00013 AT indy DOT delorie DOT com>
	<14605 DOT 19595 DOT 491155 DOT 235037 AT mercury DOT st DOT hmc DOT edu>
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

   From: Nate Eldredge <neldredge AT hmc DOT edu>
   Date: Mon, 1 May 2000 02:21:15 -0700 (PDT)

   An ordinary `open' would use blocking mode.

That's what I thought.  However, then what Zack suggested didn't make
sense to me:

    > > Therefore, I'd be willing to dump the fcntl() call entirely and open
    > > the file in blocking mode on all hosts.  Does anyone else have an
    > > opinion?

I thought that ``open the file in blocking mode'' means you need to do
something special, besides calling `open' or `fopen'.  If the normal
open does that by default, as I thought it did, then nothing needs to
be done, right?

    > Shouldn't people who do this get what they were asking for?  I mean,
    > if someone *really* wanted the preprocessor to read the tape,
    > shouldn't the preprocessor get stuck if there's no tape?

   Perhaps.  The more obvious behavior would be to complain that
   /dev/rmt0 has some problem, and abort.

Why abort?  Perhaps the user is just inserting the tape.  Why isn't
waiting for the tape (a.k.a. ``wedge'') the right thing to do?

   Yes, blocking/non-blocking has no effect when dealing with regular
   files.

So perhaps limiting that fcntl call to devices is a better solution to
this problem.  Since the DJGPP port cannot read block devices
directly, it will never get to call fcntl in the case of a tape.

(Btw, doesn't Mingw have the same problem with fcntl?)

   #include </dev/zero> will usually make
   the compiler or preprocessor slowly eat up all memory, and then die.
   This can make for a nice denial of service, especially if the system
   will kill other processes when memory gets low (Linux can).

Lucky us: DJGPP doesn't have such problems ;-).