dbus_connection_send_with_reply() shouldn't return TRUE on a disconnected connection

[Lennart Poettering]

On Fri, 17.04.09 18:05, Havoc Pennington (havoc.pennington at gmail.com) wrote:

> Hi,

Heya,

> 
> On Fri, Apr 17, 2009 at 5:46 PM, Lennart Poettering <mzqohf at 0pointer.de> wrote:
> > Currently dbus_connection_send_with_reply() returns TRUE when it is
> > tried to send a message on a disconnected connection. The only reason
> > I could see for this behaviour is that the documentation claims that
> > it would return FALSE only on OOM. But if you look closely you see
> > that the function might return FALSE on other non-OOM causes too.
> 
> If it returns FALSE for non-OOM reasons it's a bug (ignoring
> return_if_fail assertions, in those cases we're in "undefined
> behavior" zone).
> 
> If we returned FALSE for non-OOM reasons we would need a DBusError
> parameter to enable the caller to know if OOM occurred. Generally OOM
> must be handled differently from other kinds of error.

Be that as it will. Right now however the caller cannot handle non-OOM
errors at all. And I'd say the ability to handle errors at all is more
useful than the ability to distuingish the error causes.

I can't say I particularly like it that DBusConnection might just eat
my messages without saying anything.

> If you want to handle all errors the same with this function, check
> pending != NULL rather than the return value.
> 
> Given a do-over I might just make the function have a DBusError
> parameter, but, ABI is frozen.

Sure, but that's too late now, I guess.

The reason I was looking at this is that I am hacking unix fd passing
support into dbus. Now, i'd like to make
dbus_connection_send_with_reply() and friends fail if you try to send
a DBusMessage that includes unix fds on a connection that doesn't
support sending fds. Question is in absence of a seperate DBusError
parameter what's the best way to handle this? Return TRUE? Return
FALSE?

I'd have voted for FALSE. Now, you seem to suggest FALSE is for OOM
only and that's what matters.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4