Binary data file compatibility across machines

[Dale Cook]

In article <STIBER.90Nov23134600 at maui.cs.ucla.edu>, stiber at cs.ucla.edu
(Michael D Stiber) writes:
|> 
|> On different machines, the implementation of C data types is different.
|> I forget what fixed types' lengths are, but I know that at least some of
|> them may vary.  I also know that doubles can have different encoding
|> schemes (ie, IEEE vs. DEC).  Then, there's little endian machines versus
|> big endian ones.
|> 
|> So, my question is this:  Say you want to share data files among
|> different machines.  You also want to be able to use the same code on
|> each machine.  Therefore, you want to have either a uniform file format,
|> or you want the code to be able to figure out what the file format is,
|> and convert it to the native data type representation.  Now, one alternative
|> would be ASCII files --- this is guaranteed to work (assuming that you
|> can get C on an IBM 3090 to write ASCII).  However, in my application,
|> ASCII would produce files that are way too huge --- I must use a binary
|> format.  So, is there an already-existing, standard solution to this
|> problem of binary data file transfer?
|> -

Most UNIX systems have a library of routines based on the XDR protocol.
These routines will accomplish what you need to do.  Be aware, however,
that the tradeoff here is execution speed:  encoding and decoding files
to and from IEEE format can be expensive in CPU usage.

Try 'man xdr'; failing that, read your network documentation.

--- Dale Cook   cdm at inel.gov
========== long legal disclaimer follows, press n to skip ===========
^L
Neither the United States Government or the Idaho National Engineering
Laboratory or any of their employees, makes any warranty, whatsoever,
implied, or assumes any legal liability or responsibility regarding any
information, disclosed, or represents that its use would not infringe
privately owned rights.  No specific reference constitutes or implies
endorsement, recommendation, or favoring by the United States
Government or the Idaho National Engineering Laboratory.  The views and
opinions expressed herein do not necessarily reflect those of the
United States Government or the Idaho National Engineering Laboratory,
and shall not be used for advertising or product endorsement purposes.