Re: [PATCH] t1092: use GIT_PROGRESS_DELAY for consistent results

[Taylor Blau <me@ttaylorr.com>]

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