Re: [Libvir] take 2 [Re: write(2) may write less than the total requested
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