Transfering data to other architectures

[daveh@silvaco.com (Dave Halliday)]

All I am trying to say is that xdr is pretty much a standard. If your
machine supports it, it would be safer to xdr your data for transfering
between machines. Even in the case of sending a 64bit int to a 32bit
int their is a good chance that this conversion would work (if the
value can be stored in 32bits which is almost always true), xdr will
inform you if the coversion was successful or not.

For those interested in our use of xdr detailes follows:

Our problem was that we had database implementation that wrote C
structures to files that are NFS mounted between machines.  If one
machine writes the structure in its native format then another machine
reads it problems occur, the problems were the stuctures were not
compatible due to alignmet and/or byte order. We initialy overcame the
problem by padding the structures to be compatible across the machines
we supported. I am stretching my memory now but if I recall correctly
one such problem was that Sparc writes doubles to a 4 byte boundry but
the RS6000 expects doubles to be on an 8byte boundary (No problem with
byte order though). When the Alpha arrived not only did we have to
worry about special paddings but the byte order was the other way
arround, OK we could have added htonl/ntohl etc to hack our hack
solution and make it work again but what would be needed for the next
machine to come in the door, we had no way to tell.
 

The other solution was to convert the information into xdr format and
store this, this should now be portable no matter what the machine uses
as its internal representation. A machine could write all the odd bits
in byte one and all the even bits in byte two for all we cared so long
as it had an xdr interface we should not need to change a thing.

Dave.