------- 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
