🚀 go-pugleaf

keane@eng.umd.edu (Christopher Matthews Keane) writes:

>I hope this isn't a totally dodo question.... 

I'm afraid, it almost is.

>but I am trying to
>optimize USGS DEM data files for use in one of my programs.  I want to
>use binary data in the format.  I can  successfully record and read
>the binary format data using the program compiled on a SUN SS1+ using
>GCC 2.2.2 and using the exact same source, can do it using the MSDOS
>DJGPP GCC.  The files generated on the SUN and the MSDOS platforms
>have the exact same file size and everything else appears to match
>well - sizeof() etc.....  But, when I take a binary file done on the
>SUN and transfer it to DOS and try to read it - no luck - and vice
>versa.

>I am having to assume this is a file system problem - but what exactly
>is the nature of the problem --- any possible fixes?  I want to use
>the SUN for the data crunching if possible....

No, this is not a filesystem problem. Fortunately neither Unix
nor MS-DOS care what a file contains. User-level libraries may
care, but if you use read() and write(), you get data unchanged.

What you ran into is called byte sex. While beings that have
sex (excluding amoebae, etc.) are either male or female,
computers are either big endian or little endian, with a few
exceptions.

Big and little endian refer to Gulliver's travels. In our case
we have either the most significant byte stored first, or the
least significant. If you look at 16 bit words, these are the
only possibilities. When you get to 32 bit words, two mixed
cases become possible (four sexes), little/big endian in 16 bit
words, big/little endian in longs.

In your case, you have a little endian machine, the Intel CPU,
and a big endian machine, the SPARC. Writing 0x12345678 on
the Intel gives you 0x78563412 on SPARC (*not* 0x87654321 ;-).

The solution is either to write byte-wise, or to use XDR. XDR defines
a "network" representation for all basic data types, plus mechanisms
for aggregation. Sun has made the RPC/XDR source code publicly available.
-- 
| ...!unido!ukw!lupe  (German EUNet, "bang")     |  Disclaimer:            |
| lupe@ukw.UUCP       (German EUNet, domain)     |  This is an unofficial  |
| suninfo!alanya!lupe (Sun Germany)              |  opinion of Christoph & |
| Res non sunt complicanda praeter necessitatem. |  Imschweiler Consulting |