Minor DJGPP fixes

[Eli Zaretskii]

   From: Nate Eldredge <neldredge@hmc.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 ;-).