Re: invalid arguments to public API: g_assert, g_return_if_fail or continue with undefined behavior

[Matthias Clasen <mclasen redhat com>]

On Tue, 2005-09-13 at 14:10 +0100, Ross Burton wrote:
> On Tue, 2005-09-13 at 15:52 +0300, Kalle Vahlman wrote:
> > > I'd really like to have a GNOME-wide policy for dealing with public API
> > > and invalid arguments. If we feel like the traditional C route is good,
> > > we can remove all of these codeblocks for the sake of performance. I
> > > think some of the asserts/return_if_fail statements were left out for
> > > exactly that reason. I suppose this has a measurable performance impact
> > > for little helpers that are often called.
> 
> In my opinion, methods should use g_return_if_fail() to protect against
> NULL when the API docs state that NULL is an invalid argument.
> g_assert() should be used internally but it should never be possible to
> make a library call assert by passing invalid data.
> 

g_return_if_fail() is really just cosmetics over g_assert(). The GTK+
policy is that "all bets are off" after g_return_if_fail(), ie
segfaulting right after it would be ok. 

> This reminds me of a bug we had in Debian recently: Totem crashed on
> startup for a random set of users.  It turned out that GConf was being
> built with --disable-debug which had the side-effect of turning off the
> g_return_* macros, and if you didn't have a CD drive Totem would set a
> GConf string key to NULL, which is not allowed.  With the checks this is
> caught but without them it leads to a weird crash in ORBit.
>
> The moral of the story is that people really have to pay more attention
> to any errors in the console, as every warning can lead to a weird crash
> on a "production" desktop.

Thats what --g-fatal-warnings is about. 

Matthias