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 devicereal 0m0.019suser 0m0.012s sys 0m0.007sTwo 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). cheers, Padraig
