[ANNOUNCE] D-Bus 1.0 RC 1 (0.93) released
hp at redhat.com
Tue Sep 19 08:50:26 PDT 2006
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
More information about the dbus