qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v5 02/13] qtest: Don't perform side effects insi


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH v5 02/13] qtest: Don't perform side effects inside assertion
Date: Fri, 18 Aug 2017 17:03:35 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

On 08/18/2017 04:58 PM, Eric Blake wrote:
>> NDEBUG doesn't affect g_assert() (only assert(), but that wasn't in use
>> here) - I have to double-check glib documentation to see whether
>> g_assert() can be crippled in a manner similar to how I know assert()
>> can be crippled.  Ideally, we have a form that always performs side
>> effects exactly once, whether or not abort-on-error is enabled (assert()
>> does not have that, but I don't know whether glib does).
> 
> Per https://developer.gnome.org/glib/stable/glib-Testing.html#g-assert,
> G_DISABLE_ASSERT has the same compile-time effect on g_assert() as
> NDEBUG on assert().  Even worse, g_assert_not_reached() has the same
> problem.

Oh, and I failed to mention:

g_assert() has the same problem as assert() - when disabled at
compile-time, 'expr' is not evaluated.  If you want legible code (by
including side-effects within your macro that has optional
abort-on-error behavior), then you need some OTHER macro that always
performs the evaluation.  But if you create such a macro, don't use
'assert' in its name.  And I still fail to see why anyone would actually
want to disable abort-on-error behavior - once an assertion has gone
wrong, continuing execution is liable to hit follow-on problems that are
much harder to diagnose than it would have been just quitting at the
assertion failure.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]