Bug (or mis-feature) in g77 sequential file format

[Craig Burley]

>It turns out that this version of g77 for the alpha uses 8 bytes for the
>record's header and trailer (which hold the record length), while the very
>same g77 version on my PC running FreeBSD uses 4 bytes. The standard DEC
>Fortran compiler also uses 4-byte headers and trailers. This means that I
>cannot share binary files. 

I'm afraid that's a general problem in the computer industry.  Some
compiler vendors work around it, causing other problems in the process
(e.g. by wasting space on 32-bit systems like PCs, or by not
supporting records longer than 2^32 bytes on 64-bit systems like
Alphas).

In the future, we hope that g77 will provide various ways to specify
just how "portable" an unformatted file is to be.

In the meantime, g77 will probably stick with the current method
for selecting default for things like this (basically, pointer size
is used, I think), at least because compatibility (with most g77
versions to date) is worth breaking only when a truly comprehensive,
high-performance, robust solution can be simultaneously offered.

(Aside from different record-header sizes, there are other differences,
such as sizes of typical types, formats -- including endianness --
of types, and representations, e.g. whether IEEE 754 or some other
floating-point format is used.)

The upshot is, for portable I/O, use either formatted I/O or hand-roll
binary I/O using libU77 and/or C code.  Neither is ideal, however,
which is why it'd be nice to have g77 offer some better choices
someday.

        tq vm, (burley)