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 16:58:09 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

On 08/18/2017 04:39 PM, Eric Blake wrote:
> On 08/18/2017 04:33 PM, Philippe Mathieu-Daudé wrote:
>> Hi Eric,
>>
>> On 08/18/2017 06:15 PM, Eric Blake wrote:
>>> Assertions should be separate from the side effects, since in
>>> theory, g_assert() can be disabled (in practice, we can't really
>>> ever do that).
>>
>> What about the suggestion on your "Hacks for building on gcc 7 / Fedora
>> 26" series about avoid building without assertions?
> 
> 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.

Then there is the runtime switch g_test_set_nonfatal_assertions() which
affects the REST of the g_assert_*() family (such as g_assert_cmpint(),
g_assert_true(), g_assert_null()) - but NOT g_assert() proper.  And I
recall Markus has posted in the past about complaining that
g_assert_cmpint() should not be used outside of tests/.

-- 
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]