python bindings and uint16 on big-endian platforms

[John (J5) Palmieri]

Looks good to me though you have a duplicated elif:

+            elif type == TYPE_INT16:
+                num = iter.get_int16()
+                arg = 'int16:%d\n' % (num)
+            elif type == TYPE_UINT16:
+                num = iter.get_uint16()
+                arg = 'uint16:%u\n' % (num)

Can you repost the patch with one of those taken out?  Thanks.

Robert can you roll this in with your other changes when you commit
next?

On Fri, 2005-11-04 at 17:44 +0200, Johan Hedberg wrote:
> Hi,
> 
> I'm trying to implement a service which receives uint16 parameters in a
> method call. The service (actually the D-BUS daemon we're developing for
> BlueZ) is implemented using the low-level C bindings, and the client
> program used for testing it in python. What I found out was that the
> service was alway getting a zero (0x0000) value for the uint16
> parameters no matter what I sent from the python app. This was also only
> happening on my powerbook (big-endian), but not on little-endian
> machines.
> 
> I think that this behaviour is caused by the code using dbus_int32_t
> where it should be using dbus_int16_t. Attached is a patch which seems
> to solve the problem. The last part of the patch adds support for 16 bit
> integers to the __str__ method of the MessageIter class.
> 
> Johan
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus
--