Re: [PATCH v2 12/14] tests/test-logging: Fix test for -dfilter 0..0xffffffffffffffff

[Eric Blake <eblake@redhat.com>]

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 <armbru@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