On Wed, Oct 29, 2025, at 8:06 AM, Pádraig Brady wrote:
> On 29/10/2025 11:35, Bruno Haible wrote:
>> Hi Collin,
>>
>>> 'date' doesn't diagnose write errors immediately. That
>>> behavior should be changed, in my opinion.
>>>
>>> If you allowed it to run for however long it takes (hours?) to generate
>>> output, you would see a write error:
>>>
>>> $ strace date +`python -c 'print("%2147483648c" * 10000)'` 2>&1 \
>>> > /dev/full | head -n 100
>>> [...]
>>> write(1, " "..., 4096) = -1 ENOSPC (No
>>> space left on device)
>>> write(1, " "..., 4096) = -1 ENOSPC (No
>>> space left on device)
>>> write(1, " "..., 4096) = -1 ENOSPC (No
>>> space left on device)
>>> write(1, " "..., 4096) = -1 ENOSPC (No
>>> space left on device)
>>> write(1, " "..., 4096) = -1 ENOSPC (No
>>> space left on device)
>>>
>>> This patch checks for an error on the stream and returns early if there
>>> is one:
>>>
>>> $ time ./src/date +`python -c 'print("%2147483648c" * 10000)'` >
>>> /dev/full
>>> date: write error: No space left on device
>>>
>>> real 0m0.019s
>>> user 0m0.012s
>>> sys 0m0.007s
>>
>> Two considerations:
>>
>> 1) The proposed patch changes the return value of fprintftime(). Where
>> previously the return value (number of bytes output to the stream)
>> was independent of exterior conditions, now it depends on such
>> conditions.
>>
>> Thus, coding patterns like the following are not valid any more:
>> 1. Calling fprintftime with some arguments, writing to a log file.
>> 2. Allocate RETVALUE + 1 bytes of memory.
>> 3. Calling fprintftime with the same arguments, writing to an in-memory
>> stream with that bounded memory instead.
>>
>> I'm not saying that this is a likely coding pattern. But it's a possible
>> one, and that sends a red flag.
>
> I agree large outputs from fprintftime are an extreme edge case,
> but also the above cases are an extremely unlikely.
> Note the following does show one unconditional use of the fprintftime
> return in tar:
> https://codesearch.debian.net/search?q=%3D+*fprintftime+*%5C%28&literal=0
> So it might be plausible to change that and also change fprintftime()
> to return -1 on error (like fprintf).
>
The return type of fprintftime is `size_t`. But 4GiB+ of output can be
generated. If GNU still supports ILP32 platforms, the return value is already
unreliable for determining the number of bytes written.
> cheers,
> Padraig
