Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: >> diff --git a/builtin/blame.c b/builtin/blame.c >> index 8d15b68afc..e33372c56b 100644 >> --- a/builtin/blame.c >> +++ b/builtin/blame.c >> @@ -898,6 +898,7 @@ int cmd_blame(int argc, const char **argv, const char *prefix) >> unsigned int range_i; >> long anchor; >> const int hexsz = the_hash_algo->hexsz; >> + long num_lines = 0; > > Here ranges's nr is unsigned int, and the "num_lines" is an int, and the > argument to start_delayed_progress() is uint64_t, but both of "start" > and "end" are "long". I see num_lines is a long, which I am guessing was made to match what start and end are, which in turn is to use parse_range_arg(). > But we appand multiple differences to num_lines, are we sure we won't > overflow here? Looking at members of blame_entry and blame_scoreboard structures, I think we make liberal use of "int" in the blame codepath without worrying about those with 16-bit int, or those with files longer than 2G lines, and progress meter showing incorrect values to them is probably the least of our worries ;-)
