What's wrong with xdr_long in the Digital UNIX XDR routines?

What's wrong with xdr_long in the Digital UNIX XDR routines?


xdr_long is used for sending signed 32-bit values and cannot send
0xFFFFFFFF. xdr_ulong should be used instead. For 64-bit integer
values, use xdr_hyper. See the manual pages for more details.

This is slightly misleading. xdr_long() can send -1, which in 32 bits
is 0xffffffff. xdr_long() does range checking, insuring that the top 33
bits of its 64-bit argument are all ones or all zeroes. If this is not
the case, then the signed long integer is beyond the range of
representation within a signed 32-bit value, and xdr_long() rightly
fails.

xdr_u_long() [note typo above!] insures that the top 32 bits of its
64-bit argument are all zero. If this is not the case, then the
unsigned long integer is beyond ... blah blah.

So, the upshot is: If you're using signed values, use xdr_long(), and
DON'T use unsigned constants like 0xffffffff to set variables. If
you're using unsigned values, use xdr_u_long(). In both cases, make
sure you're within range for 32-bits, if you want to interoperate with
32-bit machines using native data types.



FAQ Home