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 written,
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 V
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 e
> 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?
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 ri
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 error
>>> 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 ne
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
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 ther
> 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 read).
(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), an
11 matches
Mail list logo