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

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

[Kenneth Schalk]

> We can nothing do without breaking all RPC applications on Alpha.
> This mistake was done at the very first Alpha port.
> Even fixing it in glibc with a new symbol version for backward
> compatibility breaks a lot of old programs.

Exactly what kind of code do you expect fixing this would break?

Anything which is sending these structures out on the wire unmodified is 
clearly broken as is.  Such a program would be unable to communicate with any 
RPC clients/servers with a correct implementation.

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 
data in those fields is only 32 bits, so reducing the in-memory representation 
of them from 64 to 32 bits shouldn't break anything.

If there is any code which is using the upper 32 bits of such fields to store 
extra out-of-band information in memory, they're clearly using an unwise 
64-bit specific hack and deserve to be broken.

I'm having a hard time imagining code that would be broken by such a fix and 
isn't doing something wrong already.

--Ken

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

[Thorsten Kukuk]

On Tue, May 01, Kenneth Schalk wrote:

> > We can nothing do without breaking all RPC applications on Alpha.
> > This mistake was done at the very first Alpha port.
> > Even fixing it in glibc with a new symbol version for backward
> > compatibility breaks a lot of old programs.
> 
> Exactly what kind of code do you expect fixing this would break?

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.
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".

> Anything which is sending these structures out on the wire unmodified is 
> clearly broken as is.  Such a program would be unable to communicate with any 
> RPC clients/servers with a correct implementation.

As far as I can see, everything goes through "xdr_*" which will cut it
to 32bit. 

> 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 (automatic generated code
modified later).

> data in those fields is only 32 bits, so reducing the in-memory representation 
> of them from 64 to 32 bits shouldn't break anything.

It break binary compatibility to current binaries.

> I'm having a hard time imagining code that would be broken by such a fix and 
> isn't doing something wrong already.

They do nothing wrong, I never saw a program which really uses
more then 32bit, but it is a difference if you expect a pointer to
a int or long.

Fixing this is not a big problem, but fixing all the existing
applications, which assumes longs, will break. And it would be
hard to find and fix them all. And we need every RPC function
twice in glibc: one for the old and one for the new interface.

  Thorsten

-- 
Thorsten Kukuk       http://www.suse.de/~kukuk/        kukuk@suse.de
SuSE GmbH            Schanzaeckerstr. 10             90443 Nuernberg
--------------------------------------------------------------------    
Key fingerprint = A368 676B 5E1B 3E46 CFCE  2D97 F8FD 4E23 56C6 FB4B

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

[Kenneth Schalk]

> 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