[Bug 38206] Tp::StreamTubeChannel (and subclasses) don't have unit tests

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=38206

--- Comment #5 from Olli Salli <ollisal at gmail.com> 2011-06-28 05:39:19 PDT ---
(In reply to comment #4)
> In dbus-glib, n and q (16-bit D-Bus integers) map to G_TYPE_(U)INT, int-sized
> types, which in principle might not be 32-bit - although they're 32-bit on all
> current platforms. The correct C type is g(u)int, not g(u)int16 or g(u)int32.
> 
> i and u (32-bit D-Bus integers) *also* map to G_TYPE_(U)INT.
> 
> Obviously, this loses information - dbus-glib will map G_TYPE_(U)INT back to i
> and u. So anything where dbus-glib is meant to send a 16-bit integer will come
> out as 32-bit on the wire, and yes, that makes q unimplementable (Bug #20776).
> Unfortunately, nobody wanted to do anything about this before we declared
> tp-qt4 to be stable.
> 
> In the long term, one way or another, someone has to break ABI (either tp-glib
> moving to GDBus - which can send 16-bit things - or tp-qt4 breaking its
> low-level ABI to use 32-bit throughout).
> 
> In the short term, telepathy-qt4 evades this by using permissive type
> conversion for various things: if the correct 16-bit version fails, it tries a
> 32-bit equivalent. Most uses of 'q' are values in an a{sv} anyway, where being
> picky about the difference between numeric type sizes is unhelpful.

Thanks for the summary.

I think for the case at hand this means that tp-qt4 can continue sending 16-bit
values over the bus as specified, but we just need to change the test service
to extract to a guint like gabble does (as dbus-glib will turn the 16-bit value
received from the bus to a G_TYPE_UINT).

Then, when the test service is used with tp-qt4, it'll receive 16-bit values
which get transformed into G_TYPE_UINTs in the service side. When it's used
with tp-glib client side, the cast happens already in the client side, but the
end result is the same.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.