bug#81060: tee: version 9.11: regression

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