Proposed patch for 4 byte unformatted record delimiters

[Rob Ratcliff]

Gentlemen,

Thanks for the responses!

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

Why is gfortran any different in terms of gaining general acceptance
from the world than Intel, Sun, SGI, Cray or PG (to name a few)?
The format of the unformatted file isn't specified exactly, but
we've found that they have been completely interoperable over the last
15 years on various architectures (given that we turn 
on big endian byte swapping). 

Like FX mentioned, there are unwritten
design rules that the vendors live by that are driven by the market. 
In a perfect world, one could start with a clean sheet of paper
and ignore the past, but our world is far from perfect and history
does and should matter.

I actually thought Intel's approach was a very elegant solution 
to the problem...maintaining backward compatibility while meeting
future demands...that is good and practical engineering.
 
> I think there is *nothing* to lose having this functionnality 
> optionnal. What about a -frecord-delim=(8byte|extensible) option, which 
> would default to 8byte (as we currently do) and allow us, in the 
> future, to have more possible choice about all this?

I'd go for that. It is a very simple change and solves the problem
nicely. Both camps' interests are met without really adding any 
significant amount of complexity. What more could you want? 
The customer of gfortran can decide what works best for them.
(After 10 years of GUI development, I've learned that adding an option
is the best way to resolve disagreements on behavior and such.)
 
> And I'd much like to see the simplistic "this is not standard, please 
> wander away" argument not used any more here. There are many areas 
> where the standard has less restrictions than reasonnably needed (and 
> usually enforced by all compilers). We strive to provide a compiler of 
> good quality, which includes providing a number of features not 
> required by the standard.

I appreciate that...

Thanks,

Rob