SZEDER Gábor <szeder....@gmail.com> writes:
> 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?
> 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;
