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 -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list