Portability across architectures..

Doug Gwyn gwyn at smoke.ARPA
Sun Aug 28 15:05:31 AEST 1988


In article <103 at simsdevl.UUCP> dandc at simsdevl.UUCP (Dan DeClerck) writes:
>The problem lies in writing integers as well as structures to files,
>and allow those files to be transferred between a multitude of machines
>without a data transformation taking place.

I know your main need is "Intel to Motorola", whatever that means (8086 to
68000?), but the issue is a general one and that's what I'll be discussing.

In general, a data transformation HAS to take place; the main issue is
where it is done.  If you map into some "universal" data representation,
then most architectures/implementations have to translate the data.  (If
the "universal" format matches the native binary format of some
implementation, then that implementation can take advantage of the fact.)

If one is exchanging data dynamically, e.g. via a network connection,
then it is possible to do some initial probing to discover how much
mapping is necessary and often reduce the amount of work from what
would be required if a "universal" format had been used.  I have a
package that does exactly this.

When coding up data translation algorithms in C, portability is fairly
tedious to achieve, since one can only count on AT LEAST 8 bits in a
char (there may be more), ordinary chars may sign-extend in expressions,
integers have to be built by shifting their pieces into the right place,
unions are not usually guaranteed to have the right properties, etc.
Floating-point format is even harder now that IEEE has introduced non-
numbers into the game.  And the "standard" apparently does not control
byte order within a floating-point number, so incompatibilities exist
even between IEEE implementations.

Sun's XDR spells out methods of describing structures; such descriptors
are not necessary if your application knows in advance what it will be
reading.  However, you still need some way to construct the in-memory
structure.  Even if every struct member has the same representation as
in the transferred file, there are still alignment/padding requirements
that may differ from one implementation to the next.  Generally one
ends up building a struct by translating each member separately.

Sorry there is no simple way to achieve what you're after, at least not
in general.  Don't rule out ASCII representation too quickly..



More information about the Comp.lang.c mailing list