[ANNOUNCE] D-Bus 1.0 RC 1 (0.93) released

[Havoc Pennington]

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
> this).
> 

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.

Havoc