|
From: | Eric Blake |
Subject: | Re: [PATCH v2 12/14] tests/test-logging: Fix test for -dfilter 0..0xffffffffffffffff |
Date: | Wed, 22 Apr 2020 09:49:41 -0500 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 |
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 <address@hidden> --- 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
[Prev in Thread] | Current Thread | [Next in Thread] |