On 12/9/2019 1:10 PM, René Scharfe wrote:
> Am 09.12.19 um 18:44 schrieb Derrick Stolee:
>> On 12/9/2019 12:19 PM, Eric Sunshine wrote:
>>> On Mon, Dec 9, 2019 at 12:11 PM René Scharfe <l.s.r@xxxxxx> wrote:
>>>> Am 09.12.19 um 16:36 schrieb Derrick Stolee:
>>>>> René Scharfe 0bb313a5 xdiff: unignore changes in function context
>>>>> xdiff/xemit.c
>>>>> 0bb313a5 223) xchp->i1 + xchp->chg1 <= s1 &&
>>>>> 0bb313a5 224) xchp->i2 + xchp->chg2 <= s2)
>>>>> 0bb313a5 225) xchp = xchp->next;
>>>>
>>>> Hmm, line 223 *is* exercised by t4015.85.
>>>
>>> This, along with Dscho's[1] review of an earlier coverage report,
>>> makes one wonder if there is some off-by-one error in the reporting
>>> logic, such that it is reporting the wrong lines as not covered.
>>
>> This is definitely possible. I'll see if I can locate the bug in
>> my report-generation code.
>>
>> However, line 222 is here [1]
>>
>> while (xchp != xch &&
>>
>> So if this is always false, then the rest of the while condition
>> will not be tested, nor will the body (line 225: xchp = xchp->next;).
>
> 0bb313a5 also added lines 228 and 229, which are not in the report, so
> xchp != xch must be true at least once (it is, in t4015.85).
>
> 222) while (xchp != xch &&
> 223) xchp->i1 + xchp->chg1 <= s1 &&
> 224) xchp->i2 + xchp->chg2 <= s2)
> 225) xchp = xchp->next;
> 226)
> 227) /* If so, show it after all. */
> 228) if (xchp != xch) {
> 229) xch = xchp;
Thanks for pointing out that context.
My guess is that gcov is marking the line as uncovered because the &&
operator is on that line. I'm testing [1] by breaking style conventions
and using the following:
while (xchp != xch
&& xchp->i1 + xchp->chg1 <= s1
&& xchp->i2 + xchp->chg2 <= s2)
xchp = xchp->next;
[1] https://dev.azure.com/git/git/_build/results?buildId=1453
