On Wed, May 26, 2021 at 05:46:16AM +0900, Junio C Hamano wrote: > Well, not so well X-<. It seems that some builds are not happy with > this change. See https://github.com/git/git/actions/runs/876229761 > specifically these two: > > https://github.com/git/git/runs/2669177395?check_suite_focus=true#step:7:3549 > https://github.com/git/git/runs/2669080101?check_suite_focus=true#step:6:988 > > I suspect that it has something to do with 32-bit platforms? Thanks. Of course, redirecting stderr into a file and halting after we get a non-zero exit code makes this pretty hard to debug from that output alone, but this is pretty easily reproducible on a 32-bit Docker image: root@99cfe0d56673:/git-master# getconf LONG_BIT 32 root@99cfe0d56673:/git-master# GIT_PROGRESS_DELAY=-1 ./bin-wrappers/git status fatal: failed to parse GIT_PROGRESS_DELAY Looking more closely in a debugger shows that we're failing because of this check in 'config.c:git_parse_unsigned()': if (unsigned_mult_overflows(factor, val) || factor * val > max) { errno = ERANGE; return 0; } unsigned_mult_overflows() doesn't trigger regardless of architecture, since even though val is large, factor is 1, so factor * val == val. But val is much larger than max, so we fail there. 'max' is just 'maximum_unsigned_value_of_type(long)', or 2^32-1, while val is 2^64-1. Thanks, Taylor
