This series fixes irange::legacy_upper_bound behavior for VR_ANTI_RANGE
(actually [4/5] does).  It turns out the interesting behavior is
relied on in multiple spots (maybe not so many but fixing things lead
to fixing more things when trying to understand what happens).

So apart from fixing this possible wrong-code issue it removes
the odd behavior of calling the functions with pair == 1 which is
because VR_ANTI_RANGE get num_pairs () == 2 which is because of
"reasons" (the other parts of the series show what I ran into).

I have bootstrapped and tested patches 1-4 together on 
x86_64-unknown-linux-gnu and am now testing patch 5 ontop which
looked like natural cleanup here.

I didn't try to construct a wrong-code testcase, ranger probably
never builds legacy ranges, so I'm not sure how easy it is to
get an anti-range we end up querying upper_bound on.

OK for trunk or stage1?

Thanks,
Richard.

Reply via email to