Date: Sun, 18 Mar 2001 11:37:01 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: "Mark E." <snowball3 AT bigfoot DOT com>
cc: djgpp-workers AT delorie DOT com
Subject: Re: zero fill the eof gap 2.1
In-Reply-To: <3AB401CC.27501.4C0CA2@localhost>
Message-ID: <Pine.SUN.3.91.1010318113637.11615M-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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


On Sun, 18 Mar 2001, Mark E. wrote:

> +   /* Quit when not working with a file.  */
> +   fd_info = _get_dev_info(fd);
> +   if ((fd_info == -1)
> +       || (fd_info & (_DEV_STDIN | _DEV_STDOUT | _DEV_NUL | _DEV_CDEV))
> +     return 0;

Hmm... this made me think.  Perhaps _DEV_CDEV is too broad: we don't
really know anything about the device driver and the underlying
hardware.  As an example, I think MSCDEX, the CD-ROM redirector, was
pretending to be a character device.  Although a CD is not relevant to
this issue, other device drivers might hide mass storage devices as
well.

Maybe a better option would be to leave _DEV_CDEV out of this, and
instead provide a means to enable and disable the zero-fill on a
by-handle basis?