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 32 bits. 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 http://sources.redhat.com/ml/libc-hacker/2001-01/msg00008.html
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 portability check. 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.