On Sun, 8 Nov 2026 at 10:35, Johannes Sixt [off-list ref] wrote:
On the other hand, the only case you really care about is the one that
takes an insane amount of time. If you convert only that case to printf,
then we do not need all this churn in the first place.
That's a good point -- if we want to make a minimal fix, we could
simply switch t4205 to use printf instead of "genzeros | tr".
- test-tool genzeros 2147483649 | tr "\000" "1" >expect &&
+ printf 000000000%02147483640d 0 >expect &&
I tried this out and it works on Linux but fails on macOS[1]. What
happens is that printf only outputs the nine literal zeros
("000000000") there, and silently ignores the very large padding.
[1] https://github.com/gitgitgadget/git/actions/runs/42475956442/job/128717309586
The setup and the next test still pass, since the latter compares
against the same file, and only the test expecting the exact size in
the error message notices. So I do not think we can rely on printf
for this, and I still think that generalizing the existing helper is
a reasonable way forward.
I think even if printf _would_ have worked, the end state of having
a uniform way of creating this fake data is nicer than having three
separate ways:
- genzeros when we only need NUL bytes
- genzeros | tr for small inputs that need some other byte
- printf for large inputs where "0" bytes are valid
(And if we ever need to support large inputs with a specific byte
value, we'd get stuck again, though anticipating such a need is
speculative.)
Thanks,
Kristofer