unformatted seq io record markers

[Janne Blomqvist]

On Fri, May 20, 2005 at 08:56:42PM +0000, bud davis wrote:
> i am putting together a patch that deals with this well known problem
> using a link time option.  

Ah, good. I think there was some kind of consensus that this would be
the best approach.

> gfortran -frecord_mark_g77 a.f
> 
> would select the correct routine to use g77 style record markers.  this
> would be done at link time, not compile or run time. { now is the time
> to complain about the option name, -frecord_mark_ was the first thing
> that came to mind }

Perhaps -frecord_mark=g77 (or -frecord_mark=gfortran for default
behaviour etc.)?

> while browsing through the mailing list, i found this patch:
> 
> http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01086.html
> 
> It uses the runtime environment variable approach...which creates much
> vocal displeasure from the mailing list.:):), 

Actually, it didn't use runtime env vars, but rather the library
looked out for a special command line argument when the binary was
invoked (-frecm=g77 etc. IIRC). Personally I think that was a very
ugly solution, but it was the simplest thing I could come up with so
that I could test the patch (I think the link time option that you're
apparently trying to do is the best way, but I had no idea how to
implement that).

Another cool thing one could do once the infrastructure is in place
would be to add an extra option to the OPEN statement, specifying the
kind of record markers to use. Then it would be easy to make programs
to convert between different binary file formats.

> may I use the routines posted in this patch ? Are there any copyright
> issues ?  is it from g95 and is that a problem ? (i see andy's name in
> the header of record_marker.c)  

No, there are no copyright problems that I'm aware of. I put Andys
name in the header since I copy-pasted much of the code from existing
libgfortran code (where the file in question, transfer.c, also has
Andys name in the header). So as far as libgfortran is clean,
record_marker.c is too.

Also note that at least writing of the hp format record markers is
broken, probably reading too (I haven't tested). Perhaps it's best to
skip them for the time being, they can be added later if needed once
the infrastructure is in place.

-- 
Janne Blomqvist