tags:

views:

298

answers:

2

I am receiving big endian data over UDP and converting it to little endian. The source says the integers are signed but when I swap the bytes of the signed ints (specifically 16-bit) I get unrealistic values. When I swap them as unsigned ints I get what I expect. I suppose the source documentation could be incorrect and is actually sending unsigned 16-bit ints. But why would that matter? The values are all supposed to be positive and well under 16-bit INT_MAX so overflow should not be an issue. The only thing I can think of is that (1) the documentation is wrong AND (2) I am not handling the sign bit properly when I perform a signed endian swap.

I really have two questions:

1) When overflow is not an issue, does it matter whether I read into signed or unsigned ints.

2) Is endian swapping different between signed and unsigned values (i.e. does the sign bit need to be handled differently)?

I thought endian conversion looked the same for both signed and unsigned values, e.g. for 16-bit value = value&0xff00 >> 8 | value&0x00ff << 8

Thanks

+5  A: 

You are running into problems with sign extensions in your swap function. Instead of doing this:

value & 0xff00 >> 8 | value & 0x00ff << 8

do this:

((value >> 8) & 0x00ff) | ((value & 0x00ff) << 8)

The issue is that if value is a 16-bit signed value, then 0xabcd >> 8 is 0xffab. The most significant bit stays 1 if it starts out as 1 in a signed right shift.

Finally, instead of writing this function yourself you should use ntohs().

Greg Hewgill
ntohs is not a general c library function, but a function from the (bsd) socket library. Damn useful, but a bit wierd to pull in a socket library to get endian utility functions :P
Chris Becke
It's not weird to use socket functions when you're already doing UDP communications.
Greg Hewgill
A: 

I agree, use ntoh(), hton(), etc.

jakobengblom2