libf2c/configure.in change

[Craig Burley]

>  > I think it shouldn't go in.  Pity I didn't spot that definition and
>  > its import in the beginning.  Breaking intra-platform compatibility
>  > can wait until we do inter-platform portability of unformatted
>  > files...
>OK.  We'll table this patch.

Probably that is best.

I've been so busy that it didn't occur to me, until this morning,
just how important this issue is.

(First, though, I do have to say that, because g77 is still
officially in *beta testing*, it is not so crucial as it
would be in a product that isn't.  That is, we need to work
this, and any similar, issues out once and for all during
this beta-test period.)

Basically, the problem is that libf2c, like pretty much any
Fortran run-time library, makes what amounts to its "own"
decision as to what the format of an unformatted file should be.

(In Fortran, an unformatted file is kind of like a "binary"
file in C, in that data is read or written to it at a "raw"
level.  However, this level is somewhat higher-level than in
C.  In C, one simply write()'s, or whatever, an array or struct
or whatever.  In Fortran, statements like "WRITE (10) A, B"
accomplish that -- the difference between that statement and
"WRITE (9, '(F10.5)') A, B" is that the latter specifies that
the arrays are to be written using formatted I/O, which is
like C's `printf("%f10.5",...);'.  The program that runs in
an unformatted file must match the data types, array sizes,
and lengths, basically, but not explicit layout that Fortran
doesn't really have anyway, a la C's alignment stuff.)

Because Fortran provides unformatted I/O as a *language* feature,
it's more important for a Fortran vendor (like g77) to really
understand and explain just what an unformatted file *is* in
that system.  Choices include (but probably are not limited to,
even in practice):

  1.  A file that is assumed to be read and written using
      unformatted I/O *only* in programs compiled with the exact
      same version of the compiler on the exact same kind of
      system (OS and CPU).  That is, the file is binary-compatible
      with other files written by code compiled by the exact same
      compiler, but basically no other guarantees are made.

      Programmers wanting a more "universal" format must use
      formatted I/O or write code to do the binary encoding
      directly using low-level facilities (e.g. libU77).

  2.  Same as #1, but the vendor promises to make the file "work"
      across a range of versions of the compiler on that system
      (e.g. "this compiler writes unformatted files that this and
      all future versions of this compiler will read").

  3.  Same as #1, but the vendor promises to make the file "work"
      across a range of systems the compiler and version supports.
      (Nice when sharing files across NFS, for example.)

  4.  Best of #1 plus #2.

  5.  A file that is binary-compatible with a range of *other*
      compilers that support that system.  (E.g. "this compiler
      employs an unformatted-file format that is binary-compatible
      with Smegma f77 v99.88".)

  6.  A file that is binary-compatible with some industry-wide
      standard.

As you might guess, some of the promises conflict with others
as a *default*, but they're basically all useful in different
situations.  And, the more that is promised, generally speaking,
the less performance can be delivered -- which is why some
promises are not made the *default*, because, also generally
speaking, Fortran programmers use unformatted I/O when they
*need* performance.

For example, defaulting to some industry-wide standard, or to a
single format that, say, *all* systems g77 runs on (now or in
the future), has the obvious advantages, but at least one big
disadvantage, in that, for certain systems, I/O would go *much*
slower in some cases because of endian and other differences
between the CPU architecture and the file format.

Since it would *really* be nice for g77 to at least offer all
of the above as *options*, meaning options on the OPEN statement
(this is apparently how other vendors do it), I think this
whole issue basically requires "punting" to the long-hoped-for
new run-time-library (which we cleverly code-name "libg77" ;-).

And, picking the *default* choice should be simply a matter of
just that, once all the options are available.

Whether we'll *ever* want to change the default from "whatever
g77+libf2c delivered in the past", so as to give users no hard
work to cope with reading in data written, in the past, by g77
releases, I can't say.  The fact that libf2c has already,
apparently, made an incompatible change doesn't necessarily
mean we have to.  But if that change means 64-bit systems like
Alphas get 64-bit capacity in record length, and we don't accept
it, then, while we're thus ensuring existing files get read in
"naturally", we aren't defaulting to a model whereby users of g77
on Alphas get more than an artificial 32-bit limit on their
record lengths.

I hope I've accurately laid out most of the issues above.  Mostly,
in summary, I've saying "there's a lot to think about here, and
we aren't really close yet to having enough choices in the matter".

I *think* that implies that, indeed, it's best to not "rock the boat"
in any way until we know more about what we're doing, and can
elucidate those plans better.  So indeed it seems best to not
modify g77, even in the form of netlib-sanctioned libf2c patches,
to introduce changes in the format of unformatted files on any
systems that have been supported by g77 in the past, until we
are in a better position to offer real choices to our users.

        tq vm, (burley)