Re: [PATCH] blame: report correct number of lines in progress when using ranges

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 4, 2022, 16:34 UTC
Message-ID: <xmqq5ynost82.fsf@gitster.g>
In-Reply-To: <220404.8635itl6h0.gmgdl@evledraar.gmail.com>

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

Show 13 quoted lines

>> 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 ;-)