Next: Better List-directed I/O, Previous: Uninitialized Variables at Run Time, Up: Missing Features
g77 has no facility for exchanging unformatted files with systems using different number formats—even differing only in endianness (byte order)—or written by other compilers. Some compilers provide facilities at least for doing byte-swapping during unformatted I/O.
It is unrealistic to expect to cope with exchanging unformatted files with arbitrary other compiler runtimes, but the g77 runtime should at least be able to read files written by g77 on systems with different number formats, particularly if they differ only in byte order.
In case you do need to write a program to translate to or from
g77 (libf2c
) unformatted files, they are written as
follows:
The record length is of C type
long
; this means that it is 8 bytes on 64-bit systems such as
Alpha GNU/Linux and 4 bytes on other systems, such as x86 GNU/Linux.
Consequently such files cannot be exchanged between 64-bit and 32-bit
systems, even with the same basic number format.
REC=
records) written and recl is the
record length in bytes specified in the OPEN
statement
(RECL=
recl). Data appear in the records as determined by
the relevant WRITE
statement. Dummy records with arbitrary
contents appear in the file in place of records which haven't been
written.
Thus for exchanging a sequential or direct access unformatted file
between big- and little-endian 32-bit systems using IEEE 754 floating
point it would be sufficient to reverse the bytes in consecutive words
in the file if, and only if, only REAL*4
, COMPLEX
,
INTEGER*4
and/or LOGICAL*4
data have been written to it by
g77.
If necessary, it is possible to do byte-oriented i/o with g77's
FGETC
and FPUTC
intrinsics. Byte-swapping can be done in
Fortran by equivalencing larger sized variables to an INTEGER*1
array or a set of scalars.
If you need to exchange binary data between arbitrary system and compiler variations, we recommend using a portable binary format with Fortran bindings, such as NCSA's HDF (http://hdf.ncsa.uiuc.edu/) or PACT's PDB1 (http://www.llnl.gov/def_sci/pact/pact_homepage.html). (Unlike, say, CDF or XDR, HDF-like systems write in the native number formats and only incur overhead when they are read on a system with a different format.) A future g77 runtime library should use such techniques.