Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!cmcl2!adm!smoke!gwyn From: gwyn@smoke.ARPA (Doug Gwyn ) Newsgroups: comp.lang.c Subject: Re: Portability across architectures.. Keywords: Portability, common data, files Message-ID: <8387@smoke.ARPA> Date: 28 Aug 88 05:05:31 GMT References: <103@simsdevl.UUCP> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Distribution: all Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 40 In article <103@simsdevl.UUCP> dandc@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..