Re: invalid arguments to public API: g_assert, g_return_if_fail or continue with undefined behavior
- From: Kalle Vahlman <kalle vahlman gmail com>
- To: desktop-devel-list gnome org
- Subject: Re: invalid arguments to public API: g_assert, g_return_if_fail or continue with undefined behavior
- Date: Tue, 13 Sep 2005 15:52:22 +0300
2005/9/13, Christian Neumair <chris gnome-de org>:
> I've noted significant inconsistencies wrt the handling of invalid
> arguments to functions. While GTK+ seems to take care of notifying the
> API client about failures by having various g_return_if_fail statements
> in front of virtually every public API, the EvolutionDataServer
> according to Sven Herzberg has asserts in the very beginning of many
> public API codeblocks. GnomeVFS instead often seems to not check for
> this at all, resulting in NULL strcmps etc.. Just check out
> gnome-vfs-mime-handlers.c and you get the gist.
>
> 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.
>
> 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:
http://cvs.gnome.org/viewcvs/glib/glib/gmessages.h?view=markup
---8<-----
#ifdef G_DISABLE_CHECKS
#define g_return_if_fail(expr) G_STMT_START{ (void)0; }G_STMT_END
#define g_return_val_if_fail(expr,val) G_STMT_START{ (void)0; }G_STMT_END
#define g_return_if_reached() G_STMT_START{ return; }G_STMT_END
#define g_return_val_if_reached(val) G_STMT_START{ return (val); }G_STMT_END
#else /* !G_DISABLE_CHECKS */
---8>----
So probably gnome-vfs (and any other app not doing those) should be "fixed".
--
Kalle Vahlman, zuh iki fi
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]