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

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Fri, 05 Feb 2021 20:43:30 -0500
    From:        Greg Troxel <gdt%lexort.com@localhost>
    Message-ID:  <rmio8gy3r99.fsf%s1.lexort.com@localhost>

  | 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
  | the spec says must happen.

For what I'd call detectable in advance errors (and signals) yes, I agree,
that's required (that is all the cases where you can tell simply from the
state of the world that the write cannot complete as asked).  For hardware
errors (and in that category I think include the case of a buffer that
starts out with valid addresses and continues to invalid ones, where a
SIGSEGV would perhaps also be acceptable behaviour, but if not, and EFAULT
is generated), I don't think anything is specified at all.

The standard recommends advancing the file offset to the point of the error,
but doesn't require it, and certainly doesn't require returning the number of
bytes written up to the point where the error occurs (nor does it preclude
that I believe).   This is not surprising, as what it describes is what
systems actually do, and most systems traditionally upon detecting an I/O
error, or copy{in/out} failure, simply return -1 with errno set, rather
than attempting to advise the application how much data was actually 
transferred before the error.

kre