If I have a server method that returns a string or an error, and I call it async with the glib bindings, the callback signature looks like this: static void foo_reply (DBusGProxy *proxy, char *string, GError *error, gpointer user_data); If an error was returned the string argument isn't initialised so garbage is returned. I'd expect NULL to be returned for unset values, as this means I can't simply do: if (string) g_free (string); I have to check if error is set instead.
I'm thinking if dbus_gproxy_end_call_internal, in the DBUS_MESSAGE_TYPE_ERROR case, where to create and init a GValue (and thus it is set to the default value) and then marshal that to the out values for each of them, we'll end up with integers being set to 0, strings set to NULL, and so on. Right?
There are two parts to this: * ..._end_call leaves all its "out" arguments untouched on error * the generated async_callback in dbus-binding-tool doesn't initialize its out arguments, just passes them to ..._end_call then to the user callback So we could change _end_call, but I think a more conservative fix would be to change the code-generator in dbus-binding-tool to zero-initialize the variables before calling it. For all we know, someone might be relying on ..._end_call leaving its "out" arguments untouched. Either of these has the potential problem that as soon as new code relies on it, it gains a non-obvious (hard to see) dependency on the current dbus-glib: with an older version, compilation and runtime linking will succeed, but the app will be broken. Since dbus-glib is basically dead, perhaps a better resolution would be to make dbus-binding-tool deterministically produce bad pointers (something nice and obvious like all-ones, perhaps?), and document this behaviour.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/dbus/dbus-glib/issues/7.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.