On 18/05/2026 03:45, Collin Funk wrote:
Pádraig Brady <[email protected]> writes:
-write_wait (int fd, void const *buffer, size_t size)
+write_wait (int fd, void const *buffer, ssize_t size)
It would be best to keep the same types as write()
Oh, right. For some reason I thought it used ssize_t. I guess I mixed it
up with the return type.
{
unsigned char const *buf = buffer;
- while (true)
+ while (0 < size)
I wouldn't avoid the write() with a zero size,
as that can be used to probe an fd.
(I know we don't currently, but best to leave that possibility).
Good point.
- return true;
-
- if (! wait_for_nonblocking_write (fd))
- return false;
-
+ if (written <= 0)
+ {
+ /* Continue if FD becomes writable. */
+ if (wait_for_nonblocking_write (fd))
+ continue;
+ return false;
+ }
buf += written;
+ size -= written;
}
+
+ return true;
}
Is it possible/common for write to return zero bytes when the given
size
is greater than zero?
Potentially yes.
My concern is the case where write repeatedly returns 0 and size is
always a possible as a result, leading to an infinite loop.
I could be overthinking it, since I don't think POSIX allows write to
return 0 when given a positive size. But as Paul mentioned, there are
quirky platforms like Solaris (and an unknown number of driver bugs that
could cause this). It would be nice not to cause infinite loops there.
How about treating this case as ENOSPC? This is done in src/dd.c and
Gnulib's lib/full-write.c, which quotes an old Linux bug. I've attached
a proposed patch that does that, along with adding a test using strace
to inject a write error.
This looks good at a quick glance.
Do we need the uses_strace_ thing in the test?
thanks!
Padraig
