SZEDER Gábor <> 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;

Reply via email to