[ANNOUNCE] D-Bus 1.0 RC 1 (0.93) released
hp at redhat.com
Fri Sep 15 08:44:29 PDT 2006
Kimmo Hämäläinen wrote:
> Many public functions don't make a difference between invalid arguments
> (or invalid type of arguments) and OOM. This might lead the caller to
> think that OOM happened when the arguments were invalid. I believe it is
> equally fast to return some different error code as it is to return the
> same error code for different errors (even the low-level system calls do
Do you mean the _dbus_return_if_fail() returns? Anytime you get one of
those you should assume your app crashed - behavior is undefined
afterward. An ugly warning will be printed by libdbus, as well. You
need to fix this bug in your program right away.
It's perfectly legitimate to build dbus with configure --disable-checks
in which case a failed _dbus_return_if_fail almost always _will_ crash.
Even with --enable-checks, it will segfault or get confused sometimes
when a check fails. g_return_if_fail is purely a courtesy - the idea is
that a nice warning is easier to debug than a crash.
In other words the return value from _dbus_return_if_fail is intended to
be the equivalent of rand() - it means nothing, it's not part of the
API, it's just an undefined behavior. Usually I try to pick the return
value that's least likely to crash the calling app, but if I went
through and changed all FALSE to TRUE for _dbus_return_val_if_fail
return values, that does _not_ change the guaranteed ABI or the API.
If the function has a return value for OOM, your app should treat it as
meaning _only_ OOM. It _will_ mean only OOM in all _defined_ cases where
the app is not broken/crashing. That is the API contract.
There may, however, be some functions that are ambiguous about OOM vs.
other errors for two _defined_ cases, i.e. where _dbus_return_if_fail is
not involved. If there are any functions like that, we want to know
about them and fix them.
More information about the dbus