DBus API problems & UTF-8

[Kimmo Hämäläinen]

On Mon, 2006-06-12 at 17:46, ext Havoc Pennington wrote:
> Kimmo Hämäläinen wrote:
> > For example, if dbus_message_iter_append_basic() returns FALSE, the
> > caller cannot know whether 1) an invalid argument was provided, or 2)
> > out-of-memory happened. However, the caller might want to handle
> > situation 1 differently from 2.
> 
> The boolean error code means out of memory _only_. If you provide an 
> invalid argument, that is _not_ a runtime error, it's a bug in your 

So, you require that every application verifies the object path, etc.
before calling DBus API. Ok. What about providing some API to do that?
Or should every application reimplement the validation code inside DBus?

> program. The dbus API contract is that behavior is _undefined_ if you 
> provide an invalid argument (if compiled with "enable checks" dbus will 
> be nice to you and print a warning and return, instead of crashing, but 
> if compiled without disable checks it will just get confused and crash. 
> in any case, once the warning is printed dbus makes no special attempt 
> to keep things sane and may crash later or get confused.)
> 
> The boolean return after a warning is printed is selected arbitrarily; 
> it could be true or false. Behavior is undefined at this point.
> 
> It makes no sense to provide a runtime error when an error should be 
> avoided rather than handled.

There is no problem with static strings etc. But when the data comes
from e.g. network socket or from the user and is forwarded to DBus, then
the application should have some way to validate the data beforehand.

> If there's an API function where there are two _runtime errors_ (errors 
> that have to be handled, not avoided) then there should be a DBusError 
> provided to distinguish those. Let us know if there are cases like this, 
> since it would be a bug.
> 
> However, invalid UTF-8, NULL arguments, etc. are not considered errors, 
> they are simply not allowed. Don't pass them in.

UTF-8, NULL are easy to check. But what about valid object paths, for
example? (Yes, we can replicate the code to every application and create
wrapper library for D-BUS API, but I think it's not much trouble to have
it in the DBus client library.)

BR, Kimmo