Hi On Tue, Nov 17, 2020 at 7:14 PM Markus Armbruster <[email protected]> wrote: > > g_return_if_fail(), g_return_val_if_fail() are for programming errors: > > 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. > > Unlike assert(), they continue regardless, undefined behavior be damned: > > 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. > > Except when you ask for abort(): > > To debug failure of a g_return_if_fail() check, run the code under a > debugger with G_DEBUG=fatal-criticals or G_DEBUG=fatal-warnings > defined in the environment. > > Like assert(), they can be compiled out: > > If G_DISABLE_CHECKS is defined then the check is not performed. You > should therefore not depend on any side effects of expr . > > There are just three uses outside contrib/: > > * backends/dbus-vmstate.c:232: g_return_val_if_fail(bytes_read == len, > -1); > > Marc-André, why is bytes_read != len a programming error? > > Why is returning safe?
It's "safe" as it returns -1 to indicate an error to post_load callback. Hmm, it may not be just a programming error. read_all() may return success with less bytes than requested. Here, replacing it with full error_report() may be more appropriate, since possibly the condition could happen if the input stream is malformed. I can send a patch. g_return* would be fine if it was just a programming error (checking read_all contract for example).
