log: Clean up misuse of Range for -dfilter

Range encodes an integer interval [a,b] as { begin = a, end = b + 1 },
where a \in [0,2^64-1] and b \in [1,2^64].  Thus, zero end is to be
interpreted as 2^64.

The implementation of -dfilter (commit 3514552) uses Range
differently: it encodes [a,b] as { begin = a, end = b }.  The code
works, but it contradicts the specification of Range in range.h.

Switch to the specified representation.  Since it can't represent
[0,UINT64_MAX], we have to reject that now.  Add a test for it.

While we're rejecting anyway: observe that we reject -dfilter LOB..UPB
where LOB > UPB when UPB is zero, but happily create an empty Range
when it isn't.  Reject it then, too, and add a test for it.

While there, add a positive test for the problematic upper bound
UINT64_MAX.

Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
This commit is contained in:
Markus Armbruster 2016-07-01 13:47:46 +02:00 committed by Michael S. Tsirkin
parent 5178ecd863
commit 58e19e6e79
2 changed files with 25 additions and 13 deletions

View file

@ -68,6 +68,16 @@ static void test_parse_range(void)
g_assert(qemu_log_in_addr_range(0x2050));
g_assert(qemu_log_in_addr_range(0x3050));
qemu_set_dfilter_ranges("0xffffffffffffffff-1", &error_abort);
g_assert(qemu_log_in_addr_range(UINT64_MAX));
g_assert_false(qemu_log_in_addr_range(UINT64_MAX - 1));
qemu_set_dfilter_ranges("0..0xffffffffffffffff", &err);
error_free_or_abort(&err);
qemu_set_dfilter_ranges("2..1", &err);
error_free_or_abort(&err);
qemu_set_dfilter_ranges("0x1000+onehundred", &err);
error_free_or_abort(&err);