This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: libc/2226: rpc/rpc_msg.h incorrect on Alpha
- To: Thorsten Kukuk <kukuk at suse dot de>
- Subject: Re: libc/2226: rpc/rpc_msg.h incorrect on Alpha
- From: Kenneth Schalk <schalk at cadtls dot hlo dot dec dot com>
- Date: Tue, 01 May 2001 18:06:32 -0400
- Cc: libc-alpha at sources dot redhat dot com, 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