Re: [PATCH] test-progress: fix test failures on big-endian systems
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Oct 21, 2019, 00:52 UTC
- Message-ID
- <xmqq36fmor7o.fsf@gitster-ct.c.googlers.com>
- In-Reply-To
- <20191019233706.GM29845@szeder.dev>
SZEDER Gábor <szeder.dev@gmail.com> writes:
Show 6 quoted lines
> The reason for that bogus value is that '--total's parameter is parsed > via parse-options's OPT_INTEGER into a uint64_t variable [1]... > > Change the type of that variable from uint64_t to int, to match what > parse-options expects; in the tests of the progress output we won't > use values that don't fit into an int anyway.
OK, so when the call to start_progress() is made, the second argument (i.e. "total" which now is int) is promoted to what the callee expects, so there needs no other change. Makes sense.
> [1] start_progress() expects the total number as an uint64_t, that's > why I chose the same type when declaring the variable holding the > value given on the command line.
I can sympathize, but I do not think it is worth inventing OPT_U64() or adding "int total_i" whose value is assigned to "u64 total" after parsing a command line arg with OPT_INTEGER() into the former.
Catching a pointer whose type is not "int*" passed at the third position of OPT_INTGER() mechanically may be worth it, though. Would Coccinelle be a suitable tool for that kind of thing?
Show 7 quoted lines
> int cmd__progress(int argc, const char **argv)
> {
> - uint64_t total = 0;
> + int total = 0;
> const char *title;
> struct strbuf line = STRBUF_INIT;
> struct progress *progress;