Re: Fortran/PR19303 PATCH: Runtime selection of record markers for unformatted sequential io

["Arnaud Desitter" <arnaud dot desitter at ouce dot ox dot ac dot uk>]

----- Original Message ----- 
From: "Steve Ellcey" <sje@cup.hp.com>
Newsgroups: gmane.comp.gcc.fortran
Cc: <jblomqvi@cc.hut.fi>
Sent: Tuesday, March 08, 2005 11:31 PM
Subject: Re: Fortran/PR19303 PATCH: Runtime selection of record markers for 
unformatted sequential io


> > But anyway, I personally regard HP record markers more as a
> > icing-on-the-cake feature and thus I'm not very comfortable with the
> > idea of making a grand redesign of the io library just so we can
> > implement them more efficiently. Also, even if such a decision would
> > be made, I think it would be a big mistake to start implementing it
> > before GCC 4.0.
> >
> > --
> > Janne Blomqvist


Note that the Compaq/Intel design uses only 32 bit record lengths. The idea 
is:
-  records bigger than 2Gb (2**31) are split in subrecords
-  the sign bit of the prefix indicates whether the record is continued or 
not
-  the sign bit of the suffix indicates the presence of a preceding record

IMO, it is a neat design as the record length is constant. Moreover, this 
design
is the only one published for Fortran unformatted data to the best of my
knowledge.
Arguably, it may be difficult to implement in the current gfortran RTL and 
is
incompatible with the (weird) convention of g77 on 64 bit architectures 
(record
lengths are 64 bit and therefore incompatible with files generated by g77 
compiled
code on 32 bit machines).

Regards,

> I was wondering if we should just force gfortran to use 32 bit record
> lengths on HP for 4.0.  The upside is that we do not create unformatted
> sequential files that are incompatible with the HP Fortran compiler.
> The downside is that we could not create files with records that are
> more than 2 Gig in size.  I think this is a reasonable trade-off and I
> can create such a patch if this is considered a good idea for 4.0.  I
> was thinking of setting the type of gfc_offset to a type that could be
> set in configure (based on the platform type) instead of just being set
> to off_t in libgfortran.h off_t (long int) would still be the default
> type for gfc_offset but if desired a platform such as HP could set it to
> int instead.
>
> Steve Ellcey
> sje@cup.hp.com