Date: Fri, 05 Feb 2021 20:43:30 -0500 From: Greg Troxel <g...@lexort.com> Message-ID: <rmio8gy3r99....@s1.lexort.com>
| 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