Mail Archives: djgpp-workers/2003/01/23/13:43:36
> 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.
- Raw text -