Date: Wed, 14 Mar 2001 09:29:40 -0500
Message-Id: <200103141429.JAA14360@envy.delorie.com>
X-Authentication-Warning: envy.delorie.com: dj set sender to dj AT envy DOT delorie DOT com using -f
From: DJ Delorie <dj AT delorie DOT com>
To: djgpp-workers AT delorie DOT com
In-reply-to: <Pine.SUN.3.91.1010314093834.22222E-100000@is> (message from Eli
	Zaretskii on Wed, 14 Mar 2001 09:42:55 +0200 (IST))
Subject: Re: zero fill the eof gap (complete patch)
References:  <Pine DOT SUN DOT 3 DOT 91 DOT 1010314093834 DOT 22222E-100000 AT is>
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


> I wonder whether we should really fail the operation if we cannot
> zero-fill the gap.  This seems like a subtly incompatible change: what
> if the file/device we are writing to doesn't support some of the
> trickery you do inside `_write_fill_seek_gap'?  This might break
> programs which worked until now and which don't care about leaving
> garbage in the gaps.
> 
> This is really harsh, IMHO: unless I'm mistaken, it will make all
> writes to a terminal device fail if they dare to lseek it first.
> 
> I think you should simply return zero here: it doesn't make sense to
> zero-fill gaps in writes to terminal devices.

The flag is only set if a non-beginning lseek *succeeds*.  Can that
happen for non-real-files?