[Bug fortran/23814] unformatted files from gfortran are incompatible with g77 unformatted files and solaris f95 unformatted files

["rrr6399 at futuretek dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From rrr6399 at futuretek dot com  2005-09-11 20:47 -------
Well, just to warn you, you're going to have a lot of steamed engineers on your
hands when they discover that they either have to recompile all of their FORTRAN
codes on every platform with gfortran, write all of their data (50 - 1000MB
binaries and larger) as ASCII, or convert their files to the traditional g77
format to interoperate with the rest of their processes. What will actually
happen is that users will get burnt once and then they'll drop gfortran like a
hot potato and put in a request to purchase a commercial compiler from Intel or PGI.

Another reason that this feature is so painful is that engineers tend to
pipeline their unformatted files from one process to the next. There can
literally be 10 or more programs in a process that will read from or write to a
given unformatted file. Any program in the process that was compiled with
gfortran will break the process and probably in such a subtle way that it'll
take each user hours to figure out what went wrong. (I spent four hours
on it yesterday discovering what the problem was in my process and that's with
knowing how to read the output from "od".)

Furthermore, when one writes binary in C, you get exactly what your variables
are sized to in your code. If the platform is a 32 bit machine and is IEEE
compliant, you pretty much know that a short is 16bit, an int is 32 bit, a long
is 32 bit and a long long is 64 bit. Typically, many times developers even
define macros or new types that guarantee that the variables are the same
lengths independent of 32 bit or 64 bit architectures. There are also compiler
switches many times that govern the length of the various primitive types. So if
portability of the data is important to you, the resulting binary file is
interoperable except for big-Endian versus little-Endian issues...(that can be
worked with a flag at the top or always writing in one endianess.) With C binary
files, of course, you don't have to worry about the the silly record markers
either that muck up the works.

I think the goal of allowing record lengths > 2GB is a good long time target,
but having been in the field for many years, I imagine that the current use
cases for record lengths > 2GBs are very very few compared to those involving
interoperability with other compilers and platforms. The few users requiring
>2GB record lengths can easily modify their write statement to output multiple
records as well rather than one large one.

Hopefully, once there is a compiler switch in place, everybody will be happy. :-)

p.s. It is too bad the FORTRAN spec (even the 2003) threw in the towel 
on interoperable binary files. It forces everybody to deal with these issues
in different ways using various third party libaries or ad hoc cobbled-together
solutions. As shown by the CORBA standard and others, the specification of
interoperable binary files is completely doable.

I imagine the FORTRAN vendors will continue to ensure that their binary file
format can be completely specified by the user just to meet the needs of their
customers even though the spec doesn't force them to.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23814