xdr_long and xdr_u_long should fail to encode values which
will not fit in 32-bit quantities.
They succeed currently (in glibc-2.2) but only encode the low-order
See the examples in the attached program.
(earlier versions of glibc, before 2.2, screwed up xdr_u_long on decode,
sign extending rather than zero-extending)
Created attachment 6963 [details]
test program to show failure of xdr_u_long() on oversized value
bug is likely present on all platforms where
'long' is a 64-bit integral type
Thorsten Kukuk claims glibc is correct in doing so, see
I disagree with your characterization of this as not a bug.
DEC OSF/1 -> Digital UNIX -> Tru64 UNIX has always done this range
checking since 1993. It provides a very useful and important program
For sensible interoperability between platforms with 32- and 64-bit
'long' values, these routines should fail to encode 64-bit longs.
It is absolutely broken for the routines to decode an encoded value into
something other than what was encoded. Since the types cannot possibly
fit into the range of a 32-bit value on the wire, the routines *must*
fail on encoding.