On 4/22/20 5:19 PM, Markus Armbruster wrote:
Philippe Mathieu-Daudé <phi...@redhat.com> writes:
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, ...
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?
The first form crashes when the function sets an error.
The second from crashes when the function doesn't set an error, or else
frees the error.
All clear?
Yes =) It is even documented!
* Assert that an expected error occurred, but clean it up without
* reporting it (primarily useful in testsuites):
* error_free_or_abort(&err);
Reviewed-by: Philippe Mathieu-Daudé <phi...@redhat.com>
