After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 622433 - g_log_set_default_handler does not return the user_data for the previous handler
g_log_set_default_handler does not return the user_data for the previous handler
Status: RESOLVED OBSOLETE
Product: glib
Classification: Platform
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks: 622068
 
 
Reported: 2010-06-22 20:07 UTC by Fernando Herrera
Modified: 2017-10-06 11:27 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Fernando Herrera 2010-06-22 20:07:44 UTC 
If a default handler is set with g_log_set_default_handler with associated user_data, a new call to g_log_set_default_handler will return a pointer to the previous handler but not to the associated user_data to that handler.

With the current API is not possible to stack log handlers that use user_data.
Comment 1 Sven Herzberg 2010-12-10 09:24:13 UTC 
Something like this would be nice:


> GLogFunc* old_handler = NULL;
> gpointer  old_data = NULL;
>
> old_handler = g_log_override_default_handler (new_handler, new_data, &old_data);

I'm just not sure about the name; maybe use g_log_set_default_handler_full()?
Comment 2 Philip Withnall 2017-10-06 11:27:56 UTC 
The advice is now to use the new logging API, and install a writer function using g_log_set_writer_func(), instead of using a log handler function.

g_log_set_writer_func() deliberately doesn’t return the old log writer function, because there should be none — it’s intended that the end application calls g_log_set_writer_func() exactly once, and libraries don’t call it at all.

g_log_set_writer_func() takes a GDestroyNotify so the user_data can be freed at the end of its lifetime.