On 4/22/20 4:49 PM, Eric Blake wrote:
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)
Ah OK it makes sense, thanks!
