This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: Proposed patch for 4 byte unformatted record delimiters
On Sun, Mar 12, 2006 at 04:26:18AM -0600, Rob Ratcliff wrote:
>
> It's not just Intel that would need to change.
> Right now Intel, PG, SGI, Sun, Cray would all have to change
> their approach (so that unformatted files could be
> interchanged) not to mention all the legacy code already
> compiled with g77 and other "older" compilers
> would have to be recompiled.
Of the various compilers above, which one started life
when 64-bit instead of 32-bit processors were ubiquitous?
Of the various compilers above, which one started life
when GB filesystems were common?
The above compilers have evolved from an era of "nobody
will every need more than 640 KB of memory". A 4 byte
marker provided records size that would never exist.
The Intel approach is nothing more than a kludge so that
Intel can be backwards compatible with itself. It would
be commercial suicide if Intel switched to a 8 byte marker.
gfortran's approach is simple and clean. When complexity
is added or replaces a working part of the gfortran, I
personally think we need to careful.
> (I know that the HDF5 or CGNS libraries can be used to generate
> portable binary as well, but given all of the current legacy code
> those really aren't viable solutions in the short term.
> Plus, colleagues and I have gotten a lot of mileage out of
> the very simple approach of using the standard 4-byte
> delimited unformatted file all byte-swapped to big endian.)
As pointed out by Andrew, unformatted input/ouput is processor
dependent. The standard places few if any requirements on it.
gfortran could use a 4 byte record marker and insert a NUL
after every data point.
Finally, I said I'm neither happy nor unhappy with the proposed
change. I won't oppose the change, but to say that everyone is
in agreement may be an overstatement.
--
Steve