On 04/11/2025 01:20, Collin Funk wrote:
Pádraig Brady <[email protected]> writes:
On 03/11/2025 13:09, Pádraig Brady wrote:
On 03/11/2025 06:36, Collin Funk wrote:
diff --git a/tests/misc/write-errors.sh b/tests/misc/write-errors.sh
index b33e84a3d..60496fc06 100755
--- a/tests/misc/write-errors.sh
+++ b/tests/misc/write-errors.sh
@@ -30,6 +30,7 @@ cat /dev/zero
comm -z /dev/zero /dev/zero
cut -z -c1- /dev/zero
cut -z -f1- /dev/zero
+date +%2147483648c
dd if=/dev/zero
expand /dev/zero
factor --version; yes 1 | factor
Cool.
Why pick 2^31 BTW ? Wouldn't 2^31-1 (i.e. INT_MAX) suffice?
In either case it's probably better to use getlimits and $INT_MAX (or
$INT_OFLOW if needed).
Specific numbers like this sets off all sorts of questions in my head.
BTW it's interesting that date supports $INT_OFLOW, while printf
does not:
It was based on that recent bug report. You are correct though,
getlimits_ is better.
Testing here shows date supports +%${INTMAX_MAX}c
which would be a better test anyway as $INT_OFLOW
finishes within the test timeout on my system
which would result in a false pass.
fprintftime uses off64_t for the field width. How about the attached
patch which adds off64_t to getlimits output and uses that? I think Paul
mentioned wanting to use zprintf which returns off64_t instead of int in
Coreutils. So it will likely be used in the future.
Patch looks good. Please push.
My assumption is that printf limits the field with to INT_MAX since the
C function allows you to pass it with '*' as an int argument. I could be
wrong though, I haven't looked much into it.
Ah right, that makes sense.
Your patches look good by the way. I disliked the duplicate error output
when I noticed it yesterday, but didn't think to call ferror (stdout)
for some reason.
thanks for the review.
Padraig
