[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 #4 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2011-06-28 05:18:29 PDT ---
(In reply to comment #3)
> +      guint16 port, remote_port;
> 
> -      addr = g_socket_connection_get_remote_address (connection, &error);
> +      dbus_g_type_struct_get (self->priv->access_control_param,
> +              0, &host,
> +              1, &port,
> +              G_MAXUINT);
...
> Could some dbus-glib expert give some insight here? Namely, is it wrong for
> Gabble to extract the param to a 32-bit variable? Or is it wrong for us to
> extract it into a 16-bit variable, in which case the spec needs to be
> corrected to specify u instead of q as the type of the port variable, as
> the current spec is unimplementable with dbus-glib?

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.

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