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 _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
