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
signature.asc
Description: OpenPGP digital signature