Re: [gfortran43] opening file twice...

Richard Maine wrote:

Dave Allured <nospam@xxxxxxxxxx> wrote:

Consider this definition for read access only, and for conventional
files on disk rather than more exotic devices....

Realize that when Fortran I/O was first defined, "conventional" I/O was
for tapes, where multiple independent access is pretty clearly not
reasonably viable.

Agreed.

I expect
a standards group kicked all of this around a few years ago; I just
happen to not like the current result.

My guess is more that it was left unchanged from the previous
definition, rather than that it was very actively debated. I don't
particularly recall any debates on the subject when I was on the
committee, though there might have been some from before then (I joined
in about 1991), or for that matter, there might have been some that were
quickly enough disposed of that I don't recall them.

The odds of the standard talking specifically about disk files seem...
low. It doesn't get to that level of device-specific specification for
anything else. I can imagine a note explaining that disk files were a
motivation or a likely place for some particular feature to apply, but I
can't imagine the standard actually specifying that something applies to
disk files (it could take quite a bit of work to precisely define
exactly what such a thing would mean from a standard perspective; surely
one would not want to say hardware-related things that would rule out
ramdisks, SSDs, etc.)

Good point.

What I could more imagine would be an optional specification about how
such a thing would work on the files for which it was allowed, leaving
it system dependent to specify what files it was allowed on.

I think that generic wording about system dependency would be sufficient
for the standard, with no further elaboration. Something like
"availability of multiple file connections is system dependent by type
of device". I might throw in ordinary random access hard disk files as
an illustrative example, if that did not confilct with the writing style
of the standard.

But that turns out not to be incredibly different from the current
situation. Optional stuff is often like that. Currently, you have no
guarantee that multiple opens of the same file will work. It might
happen to work as an extension on some machines/compilers. If this was
added as an optional property that some files could have, then you would
still have no guarantee that any particular machine/compiler would give
that property to any particular file. Some might; some might not. I have
trouble distinguishing these in practice.

I suppose the biggest difference might just be in the implied
encouragement of vendors to support such a thing as opposed to the
implied discouragement in the current standard. But I don't see a
concrete difference in the actual requirements. On the other hand, I do
admit that such implications have been enough to justify other additions
to the standard.

So here we come to the exact problem with an explicit prohibition on
multiple connections in the language standard. Apparently several
vendors decided that it was reasonable to allow multiple connections as
an extension, presumably to give Fortran programmers direct access to a
useful and commonly available access method. However, gfortran authors
interpreted the statement strictly and without an exception mechanism
simply because the standard said so, therefore denying what some of us
think is reasonable usage.

This does assume it would be an optional property, but I think that is
pretty much a given. Pretty much *EVERYTHING* in I/O is technically
optional. Fortunately, vendors don't tend to take the obstructionist
positions that a lawyer could probably manage to defend.

Gfortran did on this one. However I expect it was simply due to an
intent to be true to the standard, rather than to deliberately obstruct
useful applications.

(Well, I've
seen it done to try to defend what I regard as non-conforming
implementations of complex kinds, but not so much in I/O). It would be
really out of place to have everything else about I/O be optional, but
that one property not be; seems unlikely.

Perhaps it could be done as a recommendation rather than a requirement.
That might have a better chance of flying, I'd think. It wouldn't get
your guarantees, but it might improve the odds.

Because of this thread and also a live application of mine, I have given
this a lot of thought. My conclusions are (1) I should file a feature
request to gfortran to allow multiple file connections, probably by
permission from a command line option; and (2) multiple connections as a
system and device dependent feature should be added to the Fortran
standard, without an incursion into device descriptions.

Thanks to everyone for your stimulating participation on this topic. I
have been educated. ;-)

--Dave
.