View previous topic :: View next topic |
Author |
Message |
JohnCampbell
Joined: 16 Feb 2006 Posts: 2615 Location: Sydney
|
Posted: Fri Oct 14, 2011 3:11 am Post subject: binary unix files |
|
|
I have always tried to avoid this topic, but now finally have to.
I am to read an unformatted binary file that has been written by a fortran 90 program on a unix machine.
I expect the format is both big-endian and also sequential access binary, so I want to convert it to little-endian and Salford unformatted binary.
It contains integers, reals and complex numbers.
From the info I have read, I am assuming I need to:
Record length : account for the difference between the unix and salford binary format, so cope with 2-byte or 4-byte record length headers.
big-endian : convert all integer formats from big-endian to little endian, including the record headers.
( an FTN95 OPEN option something like RECORD_HEADER=('4' or '2/4') or RECORD_LENGTH=('BYTES' or 'WORDS') could solve this problem when creating a file to be read by programs compiled by other compilers )
My understanding is that reals and complex are little-endian in a unix binary file format (sourse Wikipedia), so do not need to be changed (?)
Is anyone familiar with this and could advise if my expectations are correct or not.
John |
|
Back to top |
|
 |
JohnCampbell
Joined: 16 Feb 2006 Posts: 2615 Location: Sydney
|
Posted: Fri Oct 14, 2011 8:53 am Post subject: |
|
|
I have progressed my conversion of the unix based binary files and now have binary files as Salford format with little-endian (windows) values.
I am surprised to report that, contrary to my interpretation of Wikipedia, both integers and reals are stored as big-endian in unix and need to be reversed. (works very easily with the use of an EQUIVALENCE statement) Character strings remain unchanged. It is not often I find problems with Wikipedia for technical info, but it shows you should be careful. I best read it again in case I have mis-interpreted their description.
By reading from unix binary, all record length headers and trailers were 4 bytes long and reported the record length as bytes, so no need to worry about the Salford record length syntax. A portability option of always recording the length as 4_bytes could be useful.
John |
|
Back to top |
|
 |
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2402 Location: Yateley, Hants, UK
|
Posted: Fri Oct 14, 2011 9:20 am Post subject: |
|
|
Perhaps even better would be 'COMPATIBILITY'='UNIX'/'WINDOWS' or whatever else there is out there?
Eddie |
|
Back to top |
|
 |
felix
Joined: 09 Aug 2011 Posts: 5
|
Posted: Wed Nov 02, 2011 11:39 pm Post subject: |
|
|
What is desirable is impossible. There are just too many data formats to consider for a general purpose binary file configuration. Taking the most elementary, there are at least 5 floating point formats not counting their "byte" lengths. There are 2 fixed point formats that I know of and that is not counting their byte lengths. Then you have character formats of either 7 or 8 bits. This is not counting the so-called streaming data types. Perhaps the toughest of these are from microphones, called geophones in the oil business, such that there is a file for each phone. Each of these has to be syncronized with the others to participate in crating a video for representation. And, so on..... |
|
Back to top |
|
 |
|