🚀 go-pugleaf

metzler@oddjob.uchicago.edu (Chris Metzler) writes:

>Anyway, I can use any help I can get.  I'm on a Red Hat Linux machine.
>It doesn't have full g77 installed -- f77 or g77 invokes an f2c
>preprocessor, followed by gcc.  Fortran programs compiled this way
>don't seem to be able to read Fortran unformatted binary files.

Hem, I don't know that Fortran unformatted files were ever meant to be
portable across different platforms.  It doesn't help that you don't
tell us what your "other machine" is.  Nevertheless, read on.

The Fortran I/O model is record-oriented.  On systems like Unix, where
files are unstructured sequences of bytes, Fortran unformatted records
are *usually* implemented as

    <byte count><binary data...><byte count>

where the byte count is typically a 4-byte integer.  That way, it is
easy to fseek() past one record at a time, forward or backward.  You
can verify this with the `od' utility.

I speculate that both machines use this scheme, but have different
byte orders.  You tried to read a single record and got lucky, but
your integer was jumbled.

When you do this,

>      open(80,status='old',form='unformatted',file='blah2.dat')
>      do i=1,10
>         read(80) itest
>         print*, itest
>      enddo
>      close(80)
>      stop
>      end

each read(80) must consume exactly one record.  Therefore the run-time
must check the byte counts in order to seek to the beginning of the
next record.

>produced a bogus first output of "16777216" as above, followed by
>an EOF error:

Makes sense, if the byte counts are swapped.


OK.  Here are my recommendations:

1) Don't do that.

But if you absolutely must,

2) Use od(1) profusely on both machine, to reverse-engineer
   the respective implementations and endiannesses.  Watch out for
   padding in the data blocks, you never know.
3) Write a converter, for example in C.

-- 
--Pierre Asselin, Westminster, Colorado
  lpa@netcom.com