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

[Havoc Pennington]

Kimmo Hämäläinen wrote:
> 
> It's probably dependant of the D-Bus implementation (for example, some
> implementation could check the validation of a match using information
> about existing services). If the API should be as stable as possible, we
> should not ask for trouble by specifying the API thinking only about the
> current implementation.

No worries here. Part of the API contract is that a condition outside 
the control of the application cannot result in return_if_fail. For 
example, a match rule that is syntactically invalid can return_if_fail. 
However, a match rule that just isn't acceptable to the remote process 
for some reason would have to return a DBusError.

Functions that do not return DBusError should never need to do I/O or 
talk to a remote process in order to work.

> I'm not saying that detecting OOM is impossible, I'm saying that the API
> does not make it 100% reliable in the general case (especially if the
> library implementation is changed). The library already knows when OOM
> happens, we just would need to tell the user about it.

OK, that makes sense. The answer is simply that the library 
implementation will not be changed in this way, and you can rely on 
that. If a function has a single return value that means OOM, it will 
always mean only OOM.

>> If you like, we can make the return_if_fail checks return TRUE for 
>> functions where FALSE means OOM.
> 
> The return code should only have one meaning.

It _does_ have only one meaning. That's what I am following up to try 
and explain! Just pretend the return_if_fail don't exist / are crasher 
bugs; they are not part of the API.

>> Keep in mind, I fully agree that we should add the name validation 
>> routines so people can use untrusted interface/object-path names.
> 
> I think I cannot convince you about the other issue, so I'm giving up. I
> had to try... :)

I just want to be sure you understand how libdbus works, for two reasons:
  - so you aren't writing silly error handlers in your app that try
    to "handle" return_if_fail cases instead of avoiding them
  - so you report genuine bugs where non-return-if-fail errors
    are confused with OOM return values

Havoc