From 5540e6bd9c50b7b14d5757f1af0ae024b136667a Mon Sep 17 00:00:00 2001 From: Emmanuele Bassi Date: Fri, 21 Oct 2011 21:19:27 +0100 Subject: [PATCH] docs: Document the behaviour in case of init failure Or, better, the fact that the behaviour of any Clutter function will be undefined in case the initialization fails. The value returned by clutter_init() and friends has to be handled properly. --- clutter/clutter-main.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/clutter/clutter-main.c b/clutter/clutter-main.c index 7d4d8159a..f3502531a 100644 --- a/clutter/clutter-main.c +++ b/clutter/clutter-main.c @@ -1814,6 +1814,10 @@ clutter_get_option_group_without_init (void) * error message will be placed inside @error instead of being * printed on the display. * + * Just like clutter_init(), if this function returns an error code then + * any subsequent call to any other Clutter API will result in undefined + * behaviour - including segmentation faults. + * * Return value: %CLUTTER_INIT_SUCCESS if Clutter has been successfully * initialised, or other values or #ClutterInitError in case of * error. @@ -1951,6 +1955,11 @@ clutter_parse_args (int *argc, * yourself, you can use clutter_init_with_args(), which takes a #GError * pointer. * + * If this function fails, and returns an error code, any subsequent + * Clutter API will have undefined behaviour - including segmentation + * faults and assertion failures. Make sure to handle the returned + * #ClutterInitError enumeration value. + * * Return value: a #ClutterInitError value */ ClutterInitError