On 4/22/20 8:35 AM, Philippe Mathieu-Daudé wrote:
Hi Markus,
On 4/22/20 3:07 PM, Markus Armbruster wrote:
Fixes: 58e19e6e7914354242a67442d0006f9e31684d1a
Signed-off-by: Markus Armbruster <arm...@redhat.com>
---
tests/test-logging.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/test-logging.c b/tests/test-logging.c
index 6387e4933f..8580b82420 100644
--- a/tests/test-logging.c
+++ b/tests/test-logging.c
@@ -73,10 +73,10 @@ static void test_parse_range(void)
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);
+ qemu_set_dfilter_ranges("0..0xffffffffffffffff", &error_abort);
Why sometime use this form, ...
This call must not produce an error (if it does, the test aborts,
proving we had a bug).
g_assert(qemu_log_in_addr_range(0));
g_assert(qemu_log_in_addr_range(UINT64_MAX));
-
+
qemu_set_dfilter_ranges("2..1", &err);
error_free_or_abort(&err);
... and then this other form?
This call must produce an error (if we do not diagnose the caller's
error, our code is buggy, and the test must fail)
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
