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

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.

> > On the other hand, programmers using our API will probably kill us if we
> > remove them. So maybe we've got to make a decision whether we should
> > enforce the usage of g_assert or g_return_if_fail.
> I think there is no reason to leave them out as:

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.

Ross Burton                                 mail: ross burtonini com
                                          jabber: ross burtonini com
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]