On Monday 03 May 2010 20:54:17 Simon McVittie wrote: > 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.
Tp-Qt4 actually crashes, but *not* due to QtDBus. qdbus_cast, by default, returns a null pointer if the cast does not succeed. This means that the structure is referring to a null pointer and hence triggers a crash as soon as it gets accessed. So QtDBus is not leading to a crash - hence my proposal for the workaround using 2 different structs. For now, we can simply push a quick fix which avoid the crash - which is just checking if *addr == 0. > > 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. Yeah, I agree completely - also consider that we can change only the methods which return a q. Passing a q as an argument is not a problem, even if the day a CM gets written with tp-qt4, the above assumption is no longer true. So the long term solution is changing q->u everywhere in the spec. > > > 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. Ok - let me know what the final decision will be, so we can act accordingly :) > > > 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 > _______________________________________________ > telepathy mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/telepathy -- ------------------- Dario Freddi KDE Developer GPG Key Signature: 511A9A3B
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
