Date: Thu, 23 Jan 2003 20:41:38 +0300
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: rich AT phekda DOT freeserve DOT co DOT uk
Message-Id: <2427-Thu23Jan2003204136+0200-eliz@is.elta.co.il>
X-Mailer: emacs 21.3.50 (via feedmail 8 I) and Blat ver 1.8.9
CC: djgpp-workers AT delorie DOT com
In-reply-to: <3E2FC531.F37C6D24@phekda.freeserve.co.uk> (message from Richard
	Dawe on Thu, 23 Jan 2003 10:34:25 +0000)
Subject: Re: readv, writev [PATCH]
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1030123082200 DOT 15630D AT is> <3E2FC531 DOT F37C6D24 AT phekda DOT freeserve DOT co DOT uk>
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

> Date: Thu, 23 Jan 2003 10:34:25 +0000
> From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
> 
> Say you write the first part of the data, but then the write for the next part
> fails. What do you return? The call has failed, but you have written some
> data. It seems to me that it would be hard for a program to recover gracefully
> from this, since it doesn't know what has been written to the file.

What is teh common practice in other implementations?  Like glibc,
for example?

> If writev were to write iov-by-iov and one call failed, it would need to seek
> to the position that it was at, before writing. This is to ensure:
> 
> 1. that a retry will overwrite the data;
> 2. that we read from the position where the writes started.

I'm not sure I understand this: what retry are we talking about here?
Also, read after write requires an lseek, right?

> * It should cope with non-blocking write calls.

Is this relevant for DOS?  We don't support non-blocking I/O.

> > Can't you use _read instead?  Is readv supposed to handle text files and
> > do CRLF->NL conversions?
> > 
> > The same holds for _write in writev.
> 
> I assumed that readv, writev were just vector-input versions of read, write
> and so should have the same CFLF->NL conversion characteristics.

From the function's descriptions, it sounds like they are for binary
data, but I might be mistaken.  Does anyone know what does Cygwin do
in this case?

> > And please don't forget an entry in wc204.txi.
> 
> Something like this:
> 
> @findex readv
> @findex writev
> The @code{readv} and @code{writev} functions were added.

Yes.