Eric SunshineWhen coalescing ranges, sort_and_merge_range_set() unconditionally assumes that the end of a range being folded into a preceding range should become the end of the coalesced range. This assumption, however, is invalid when one range is a subset of another. For example, given ranges 1-5 and 2-3 added via range_set_append_unsafe(), sort_and_merge_range_set() incorrectly coalesces them to range 1-3 rather than the correct union range 1-5. Fix this bug.
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> ---
Presumably, this problem does not happen in practice, so it's not clear if the patch should be applied. I discovered it when teaching git-blame to accept multiple -L options, one iteration of which (after making the range_set API public) employed sort_and_merge_range_set() to sort and coalesce input -L ranges added via range_set_append_unsafe().
It might make sense to apply this patch in order to future-proof sort_and_merge_range_set() in case the range_set API ever becomes public.
line-log.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
Show changes to line-log.c +2 −1
diff --git a/line-log.c b/line-log.c index 4bbb09b..8cc29a0 100644 --- a/line-log.c +++ b/line-log.c @@ -116,7 +116,8 @@ static void sort_and_merge_range_set(struct range_set *rs) for (i = 1; i < rs->nr; i++) { if (rs->ranges[i].start <= rs->ranges[o-1].end) { - rs->ranges[o-1].end = rs->ranges[i].end; + if (rs->ranges[o-1].end < rs->ranges[i].end) + rs->ranges[o-1].end = rs->ranges[i].end; } else { rs->ranges[o].start = rs->ranges[i].start; rs->ranges[o].end = rs->ranges[i].end;
-- 1.8.3.2