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
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

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?

- Raw text -