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

[Thorsten Kukuk <kukuk at suse dot de>]

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