siggins@kodak.com (Richard Siggins, B-150B, Eastman Chemical Company Research, X- 3762) (04/06/91)
As a new UNIX systems person I was dismayed to discover that floating point and integer numbers are not stored in the same format in a binary file on ULTRIX vs most other UNIX systems. It seems that the bytes are in the reverse order or some similar condition. Does anyone know of a file transfer method that will correctly translate the data? In particular I am interested in data from an IBM RS6000 and a DECsystem 5000. Thanks. +-----------------+ | ___ ________ | Richard Siggins | | / / | | Eastman Chemical Company | | / / | | Research Laboratories, B-150B | |< < K O D A K| | Kingsport, TN 37662 | | \ \ | | (615) 229-3762 FAX (615) 229-4558 | |__\ \________| | email: siggins@kodak.com | | +-----------------+
gwyn@smoke.brl.mil (Doug Gwyn) (04/06/91)
In article <26467@adm.brl.mil> siggins@kodak.com (Richard Siggins, B-150B, Eastman Chemical Company Research, X- 3762) writes: >As a new UNIX systems person I was dismayed to discover that floating point and >integer numbers are not stored in the same format in a binary file on ULTRIX vs >most other UNIX systems. This has nothing to do with Ultrix or Unix -- binary data files are inherently unportable. Why not convert them to text then transport that.
adrianho@barkley.berkeley.edu (Adrian J Ho) (04/06/91)
In article <26467@adm.brl.mil> siggins@kodak.com (Richard Siggins, B-150B, Eastman Chemical Company Research, X- 3762) writes: >As a new UNIX systems person I was dismayed to discover that floating point and >integer numbers are not stored in the same format in a binary file on ULTRIX vs >most other UNIX systems. It seems that the bytes are in the reverse order or >some similar condition. It's actually a problem with the architecture used (VAX, MIPS) -- nothing to do with Ultrix. > Does anyone know of a file transfer method that will >correctly translate the data? In particular I am interested in data from an >IBM RS6000 and a DECsystem 5000. There is no general file transfer method that handles arbitrary-endian data. Your best bet is to *convert* the files before transferring them. To do that, you have to know the exact format of the data files. Once you know that, all you have to do is write a program that reads in each data item (depending on the size), reverses the bytes (*not* the bits), and writes it back out again. One more thing: If you have the sources to the programs you run, and anticipate the need to transfer data amongst several different architectures, consider writing out your data in ASCII format. IMHO, it's the only truly portable data format, and you'd only have problems if (a) you have limited disk space [get some more], (b) the data values generated are too large for the destination architecture (eg. trying to store 2^48 in a 32-bit integer) [scale your data if possible], or (c) you use EBCDIC ["dd" to the rescue 8-)]. Good luck!