Jim Meyering wrote:
It *could* perform that test, but I think it is slightly more maintainable (no duplication of that potentially nontrivial expression) and just as correct to check only "ret < 0".
Not having the duplicated expression is certainly good, if it's correct to do so (and it seems you're right).
but it's still possible for it to return less than requested if write() returns 0 (eof?).
Really? How? EOF is relevant to read, but not to write(2).
As I see it, calling safewrite can have only two outcomes: - return -1 to indicate failure - return the requested byte count (arg #3, count, which is non-negative) The only way safewrite can return 0 is if its "count" argument is also 0, and that's not a failure. This is because write itself can return 0 only if its count is also 0.
Hmm, I was thinking write might return 0 for closed pipes and similar but you're right, that's different from EOF and should return error. http://www.opengroup.org/onlinepubs/000095399/functions/write.html says: Where this volume of IEEE Std 1003.1-2001 requires -1 to be returned and errno set to [EAGAIN], most historical implementations return zero (with the O_NDELAY flag set, which is the historical predecessor of O_NONBLOCK, but is not itself in this volume of IEEE Std 1003.1-2001). The error indications in this volume of IEEE Std 1003.1-2001 were chosen so that an application can distinguish these cases from end-of-file. so we're safe here. It does bring up the point that safewrite() doesn't handle EAGAIN and might not be appropriate for non-blocking fds. The sigwrite pipe is non-blocking. At quick glance, the qemud fds might be that way too? It also makes me notice that we have 3 *SetNonBlock functions, two with the same name even... -jim