Validation of paths, interfaces, members etc.

[Simon McVittie]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 09 Jan 2008 at 20:39:49 +0100, Marcin ‘Qrczak’ Kowalczyk wrote:
> It's hard to tell to what extent the goal has been achieved, but one
> place where I'm fairly sure that it's tricky to detect errors which
> libdbus treats as programs errors is validation of various forms of
> strings. I mean that libdbus doesn't export functions which do the
> validation, so the only way to protect against libdbus errors is to
> duplicate the validation by hand (except address validation which is
> reported through DBusError). Am I missing something? Why aren't
> validation functions exported?

I've made the same complaint in the past (I'm the current maintainer of
the D-Bus Python bindings). A lot of dbus-python holds libdbus at arms'
length and manipulates it very carefully in an attempt to stop it
asserting... I do intend to make this better, though (I was thinking
about it this morning in fact).

I plan to get public validation functions (based on those in dbus-python),
which raise an appropriate DBusError, into libdbus at some point, and also
make the corresponding change in dbus-glib (raising a GError).

The current private validation functions aren't particularly friendly,
since they don't indicate why the object-path (etc.) was invalid -
the ones I add will raise a DBusError with a message though.

For the moment feel free to cut and paste my validation functions from
_dbus_bindings/validation.c in dbus-python, altering as appropriate for
non-Python (they're MIT licensed, like libdbus).

> Another place which need some additional error checking is registering
> the same path multiple times. This can easily be checked with
> dbus_connection_get_object_path_data (assuming that I always use
> a non-NULL pointer as the data of course), even if I would prefer
> dbus_connection_register_{object_path,fallback} to indicate the status
> with its return value instead of calling _dbus_warn.

I've already submitted a patch for this, which will be in the next
release. (dbus_connection_try_register_object_path and
_register_fallback)

dbus_connection_register_* can't indicate the status with its return
value, because a NULL return value is defined to mean "out of memory".
Again, you're not the first to complain about this... any dynamic
language will have the same problem.

Note that checking via dbus_connection_get_object_path_data isn't
thread-safe. My patch in current libdbus takes appropriate locks, so it
*is* thread-safe.

    Simon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHhUwXWSc8zVUw7HYRAjSTAJsFosrXIo/ado43JxSehrBv9IaHGACeL1ch
dX690MivVGZ3JystDuxxI7U=
=+/iH
-----END PGP SIGNATURE-----