Re: partial failures in write(2) (and read(2))

2021-02-18 Thread David Holland
On Tue, Feb 16, 2021 at 05:29:00PM +0700, Robert Elz wrote: > We could, of course, invent new interfaces (a write variant with an > extra pointer to length written arg perhaps, or where the length arg > is a pointer to a size_t and that is read and then written with either > the amount

Re: partial failures in write(2) (and read(2))

2021-02-16 Thread Robert Elz
Date:Mon, 15 Feb 2021 23:18:33 +0100 From:Rhialto Message-ID: | A system call with error can return with the carry set and the error and | short count returned in a separate registers. The carry bit is how | errors used to be indicated since at least V7 (even

Re: partial failures in write(2) (and read(2))

2021-02-15 Thread Rhialto
On Thu 11 Feb 2021 at 09:41:50 -0500, John Franklin wrote: > From the application?s perspective of calling write() in libc, when > there is such an error the libc function could return a short response > and set errno. That doesn?t work so much for the kernel?s system > call. A system call with

Re: partial failures in write(2) (and read(2))

2021-02-11 Thread Edgar Fuß
> I suppose libc could set a default handler for the new signal, and do some > extra work to set errno. Then the libc routine could better use a new syscall, no?

Re: partial failures in write(2) (and read(2))

2021-02-11 Thread John Franklin
On Feb 10, 2021, at 18:28, Thor Lancelot Simon wrote: > > On Fri, Feb 05, 2021 at 08:10:06PM -0500, Mouse wrote: >>> It is possible for write() calls to fail partway through, after >>> already having written some data. >> >> It is. As you note later, it's also possible for read(). >> >> The

Re: partial failures in write(2) (and read(2))

2021-02-10 Thread Thor Lancelot Simon
On Fri, Feb 05, 2021 at 08:10:06PM -0500, Mouse wrote: > > It is possible for write() calls to fail partway through, after > > already having written some data. > > It is. As you note later, it's also possible for read(). > > The rightest thing to do, it seems to me, would be to return the

Re: partial failures in write(2) (and read(2))

2021-02-10 Thread Mouse
>>> It is possible for write() calls to fail partway through, after >>> already having written some data. >> The rightest thing to do, it seems to me, would be to return the >> error indication along with how much was successfully written (or >> read). But that, of course, requires a completely

Re: partial failures in write(2) (and read(2))

2021-02-06 Thread Robert Elz
Date:Fri, 05 Feb 2021 20:43:30 -0500 From:Greg Troxel Message-ID: | An obvious question is what POSIX requires, pause for `kill -HUP kred` :) Hey! wiz is the daemon, I'm an angel... | I think your case (a) is the only conforming behavior and obviously what

Re: partial failures in write(2) (and read(2))

2021-02-05 Thread Greg Troxel
David Holland writes: > Basically, it is not feasible to check for and report all possible > errors ahead of time, nor in general is it possible or even desirable > to unwind portions of a write that have already been completed, which > means that if a failure occurs partway through a write

Re: partial failures in write(2) (and read(2))

2021-02-05 Thread Mouse
> It is possible for write() calls to fail partway through, after > already having written some data. It is. As you note later, it's also possible for read(). The rightest thing to do, it seems to me, would be to return the error indication along with how much was successfully written (or

partial failures in write(2) (and read(2))

2021-02-05 Thread David Holland
(This came up in chat, and since there was no agreement at all there it seems it ought to be discussed here.) It is possible for write() calls to fail partway through, after already having written some data. We do not currently document the behavior under these circumstances (though we should),