[Telepathy] [PATCH] Fix crashes in FileTransfer and StreamTubes related to SocketAddressIPv4

[Simon McVittie]

Does telepathy-qt4 actually *crash* when the type is not as expected, or just
not work? If it crashes, that's a separate bug (D-Bus applications shouldn't
crash, regardless of what they receive from D-Bus). If it just doesn't work,
that's OK.

On Mon, 03 May 2010 at 20:18:18 +0200, Dario Freddi wrote:
> It would be a workaround changing the spec _only_ in tp-qt4, where we would 
> actually end up having an inconsistency.

Right, if telepathy-qt4's spec/ directory differs from the official
language-neutral one in telepathy-spec then that's a bug.

The problem is that telepathy-glib claims to implement the language-neutral
spec, but can't (because dbus-glib can't); so either we need to change the
language-neutral spec to what we've (in practice) always implemented, or
special-case the 16-bit types.

Changing telepathy-spec would break interop with any CM that implements the
spec as written, but I don't think we have any non-GLib connection managers
that do File Transfer or Tubes, so the worst that can happen is that
avatar requirements from the Python CMs (Butterfly, Sunshine etc.) are broken.

> The real solutions are:
> 
>  * Apply my changes to the whole Telepathy spec
>  * Fix dbus-glib and make all CM adhere to the spec
> 
> If both of them are not possible, I can add a real workaround, which consists 
> in adding another structure with signature (su) as a private type, and cast to 
> that structure if casting to (sq) fails.

Fixing dbus-glib isn't really feasible either (it'd be an ABI break in
dbus-glib!), so we either dig up my branch from fd.o #20776 or your
presumably-equivalent changes (i.e. change telepathy-spec to match what we
always implemented in GLib-land), or work around the few current 16-bit types
in telepathy-qt4 and avoid adding any more, or both.

> IMHO, using a different spec for tp-qt4 and tp-glib is asking for trouble

Yes, I agree. The problem is that Telepathy happened first in GLib and Python;
dbus-glib is unable to implement the language-neutral spec as designed,
but because Python is extremely permissive about types, nobody noticed.

    Simon