Re: libc/2226: rpc/rpc_msg.h incorrect on Alpha

[Kenneth Schalk <schalk at cadtls dot hlo dot dec dot com>]

> Every Code which codes their own functions using for example xdr_long
> to access this data will break. They expect a long, but there is only
> a int32_t with not enough space.

They expect a long only because that is the current, incorrect convention.  
The RPC/XDR on the wire notion of "long" is a 32-bit value.

> The last time I looked at this to fix this, I found out that some
> common used programs (like rpc.nfsd, but I'm not sure about this,
> it's 2 years ago) will not work any longer. The reason is, that 
> rpcgen was used for the most programs, which prefers "long".

Couldn't rpcgen, which is part of glibc, just be fixed too?

> > Programs which use these data structures in memory only and use XDR or the 
> > like to convert to/from packets should be unaffected by a fix.  The network 

> No, they will break because they use xdr_long

Isn't the use of the "long" XDR functions, rather than the "int32" ones, 
deprecated for exactly this reason?  For example, in rpc/xdr.h it says:

/* WARNING: The IXDR_*_LONG defines are removed by Sun for new platforms
 * and shouldn't be used any longer. Code which use this defines or longs
 * in the RPC code will not work on 64bit Solaris platforms !
 */

It seems to me that code which assumes, or is based on the assumption, that 
sizeof(long) == 4 is just as bad as code which assumes sizeof(int) == 
sizeof(void *).  Such code is asking for trouble and deserves to break.  While 
code which is using a long * to read/write 32-bit values, as apparently 
xdr_long does on Alpha Linux, may be a borderline case, it's still incorrect.

> (automatic generated code modified later).

Yuck.  I would hope that there are relatively few programs out there that made 
such a poor choice.

--Ken