The coding convention for the dbus library is to report errors through a DBusError (analogous to a GError or a C++ exception) so that they can be caught and handled by application code in whatever way is most appropriate for the application. In particular, this avoids corrupting stdout/stderr if the application is using them for something machine-readable.
However, the Windows implementation of _dbus_get_autolaunch_address() doesn't do that consistently:
if (!SearchPathA(dbus_module_path, daemon_name, NULL, sizeof(dbus_exe_path), dbus_exe_path, &lpFile))
dbus_set_error_const (error, DBUS_ERROR_FAILED, "could not find dbus-daemon executable");
retval = FALSE;
fprintf (stderr, "please add the path to %s to your PATH environment variable\n", daemon_name);
fprintf (stderr, "or start the daemon manually\n\n");
(This is after Bug #103601 - before that, it used printf to stdout, which was worse, because stdout is more likely to be used for machine-readable output.)
The warnings that are currently printed to stderr should probably move into the message part of the DBusError. It's OK for a DBusError to be reasonably long.
In library code, we should only emit warnings to stderr as a last resort when nothing else is possible (and if we do that, we should use _dbus_warn() instead of fprintf).
I'm not intending to fix this myself, since I don't develop on Windows and so can't meaningfully test this.
-- 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/issues/191.