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

[Kimmo Hämäläinen]

On Fri, 2006-09-15 at 18:44, ext Havoc Pennington wrote:
> 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.

Yes, it's a bug, but I don't understand why D-Bus library should make it
more difficult to fix the bug. Think about the time when developing the
client program -- the more error codes/messages the easier for the
developer. Also, there should be a way to handle these errors in
run-time because some of us (with bad genes?) make mistakes that are not
caught in development time (asserts are not an alternative here).

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

This crashing client library is another thing I don't understand. I
simply don't understand why the library should 'punish' the user instead
of helping him to develop robust programs. If there is a crash, at least
the reason should be told (e.g. by returning an error code). I believe
this is a must for some high-level bindings as well, so that they can
raise an exception instead of just crashing.

> 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 client is buggy, return random garbage to it." Isn't that
punishing instead of helping?

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

The contract must tell exactly what can be returned and when. There is
no disclaimer 'your program must be bug-free'. What other API than the
D-Bus API requires this? Different error codes make defining the
contract easier (otherwise one has to say 'well, there is also this and
this case when it returns NULL...'). (However, I'm not asking breaking
the API/ABI, this could be also achieved by adding some new API.)

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

I'm just telling you something I have learned while developing an
embedded Linux system. In such a swapless, low-RAM system we sometimes
might want to deny memory allocations of an application to prevent the
whole system from crashing. Technologies such as Glib (which just calls
abort() on OOM) do not make this easy (actually pretty impossible).
D-Bus is used also in the lowest levels, so it should allow extremely
robust programs.

If there is a small thing we can do to make the developer's life easier,
why not do it?

BR; Kimmo

> 
> Havoc
>