diff options
author | Markus Armbruster <armbru@redhat.com> | 2016-07-01 13:47:46 +0200 |
---|---|---|
committer | Michael S. Tsirkin <mst@redhat.com> | 2016-07-04 16:49:33 +0300 |
commit | 58e19e6e7914354242a67442d0006f9e31684d1a (patch) | |
tree | 30f96c226f88deface835a5a3a2dd90134f5e1a5 /qapi/string-output-visitor.c | |
parent | 5178ecd86367090a59af0e15e67cee6f673aaa08 (diff) | |
download | qemu-58e19e6e7914354242a67442d0006f9e31684d1a.zip qemu-58e19e6e7914354242a67442d0006f9e31684d1a.tar.gz qemu-58e19e6e7914354242a67442d0006f9e31684d1a.tar.bz2 |
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>
Diffstat (limited to 'qapi/string-output-visitor.c')
0 files changed, 0 insertions, 0 deletions