GNOME Bugzilla – Bug 741732
G_DISABLE_ASSERT doesn't disable g_assert_cmpint and friends
Last modified: 2018-05-24 17:21:24 UTC
There exists a macro G_DISABLE_ASSERT which, when defined, causes g_assert() and g_assert_not_reached() to be eliminated from the build, with the intent that the final stable build of an app is not polluted with these development/debugging statements. There are extended versions of these methods, such as g_assert_cmpint(), with the intent that when an assertion fails, the actual vs. expected values can also be printed, rather than just purely stating that it failed. However, defining G_DISABLE_ASSERT leaves the g_assert_cmpint() and friend macros intact, they will remain in the build. I see no point in this behavior, I believe the right approach would be if all the g_assert_* macros shortcut to no-op in presence of G_DISABLE_ASSERT. (I understand such a change might breaks apps which define G_D_A and have expressions with side effects inside a g_assert_something(), but I hope such a change is acceptable for the next stable series.)
there's a fundamental difference in the API, that sadly reflects a larger design issue. the g_assert_* family of functions is meant to be used when writing a test suite using the GTest API. it serves no purpose to disable those functions, and they actually do not always cause an abort(). g_assert(), on the other hand, is something that lives on its own. to be fair, the whole idea of being able to disable assertions for internal state consistency checks is ludicrous, and should just not have happened — but if wishes were horses, today, we'd have: * a propert assert() API for internal state checks * a propert unit testing API * possibly, a bunch of horses I'd be very unhappy if G_DISABLE_ASSERT caused changes in the unit testing API; it'd cause any test suite we have to allow weird states, with either random crashes, or, worse, to pass just because somebody added a G_DISABLE_ASSERT in the pre-processor flags.
(In reply to comment #1) > I'd be very unhappy if G_DISABLE_ASSERT caused changes in the unit testing API; > it'd cause any test suite we have to allow weird states, with either random > crashes, or, worse, to pass just because somebody added a G_DISABLE_ASSERT in > the pre-processor flags. It already does though; lots of test programs use plain g_assert() (or g_assert_not_reached(), which is also disable-able). But clearly it makes no sense to run test programs that you built with assertions disabled. Maybe we should change gtestutils.h to do: #if defined (G_DISABLE_ASSERT) || defined (G_DISABLE_CHECKS) #define g_test_init(argc, argv, ...) G_STMT_START { g_printerr ("Built with G_DISABLE_ASSERT or G_DISABLE_CHECKS; test programs cannot be run\n"); exit (1); } G_STMT_END #else ... #endif
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/976.