python bindings and uint16 on big-endian platforms

[Robert McQueen]

I'd be happier merging this patch if it had a test case (patch
test/python/test-client.py). I know it's a trivial change but we'd have
found the problem in the first place if some of the test code actually
covered these types - I discovered a couple of days ago that booleans
were broken, but nobody had noticed as yet.

I'd offer to write the test case myself and commit it, but a) every time
I've written a test case, I've found something else in the bindings
that's broken and had to go and fix it (underlining the need for these
tests in the first place), and b) I'm quite busy with work and really
not meant to be hacking D-Bus indefinitely. So, please write a test
case, fix the newly-exposed bugs, and send an updated patch. :)

Regards,
Rob

John (J5) Palmieri wrote:
> No sorry it is my fault missed the u.  A bit tired after the daylight
> savings change.  Patch is good as is.
> 
> On Sat, 2005-11-05 at 02:34 +0200, Johan Hedberg wrote:
> 
>>On Fri, Nov 04, 2005, John (J5) Palmieri wrote:
>>
>>>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.
>>
>>Hmm, maybe I'm missing something, but how is that a duplicate? One is
>>for INT16 and the other for UINT16.
>>
>>Johan