Proposal: make criticals fatal by default
The documentation of g_critical() says:
Critical warnings are intended to be used in the event of an error that originated in the current process (a programmer error). Logging of a critical error is by definition an indication of a bug somewhere in the current program (or its libraries).
i.e. they are soft assertions that indicate a bug without crashing the program. Because criticals are bugs, by definition, it should be OK to change the behavior of criticals without breaking any API guarantees. I'd like to turn all criticals into crashes. This will improve the quality of software that depends on GLib. If we were writing GLib for the first time in 2022, there's no way we would allow program execution to continue after a known programmer error: it might have seemed like a good idea 25 years ago, but not by today's standards. Criticals generally indicate quite serious issues (e.g. misuse of handle IDs) and should not be ignored. Fatal criticals by default will also make bug reporting easier for users, as the first step in many bug reports is to ask the reporter to run the program with G_DEBUG=fatal-criticals
and take a backtrace again. It's easier to just do this from the start. Additionally, distro crash reporters will now find bugs that would have previously gone unnoticed and unreported unless users are looking carefully at their system journals.
Note this would NOT make g_critical() akin to g_error(). The difference is that g_error() is guaranteed to crash the program. g_critical() would not be guaranteed to do this. We might provide a G_DEBUG
value to make them soft again, for example. And although criticals are already fatal in tests, we allow trapping them, so don't want them to immediately crash the program when running tests.
Also note this would affect macros like g_return_if_fail(), which are already documented to indicate bugs. Here, the documentation says:
If expr evaluates to FALSE, the current function should be considered to have undefined behaviour (a programmer error). The only correct solution to such an error is to change the module that is calling the current function, so that it avoids this incorrect call.
[...]
To make this undefined behaviour visible, if expr evaluates to FALSE, the result is usually that a critical message is logged and the current function returns.
I think that's more than enough wiggle room to switch things to crash by default.
The short term effect of this change would be to increase the number of crashes users see, which will be sad. But the long term effect of this change would be to reduce software misbehavior across the entire GLib ecosystem, which will be worth it. Proposed timeline would be to land this change immediately after glib-2.74 branch is created. That way, we have the entire 2.76 release cycle to get cold feet and change our minds if too much breaks.