glen herrmannsfeldt <
g...@ugcs.caltech.edu> wrote:
[from elsethread]
> It is an interesting question. For sequential the standard describes
> records, and there is some question about an unterminated file end.
> That is, the last line may or may not be a record.
I disagree that there is a question about tis in the standard. The
standard describes a sequential file as being composed of records. It
has no concept of a "line that is not a record" or anything else of the
sort. I don't see any "question" at all about this in the standard for
sequential files. If it isn't a record, then it isn't part of a
sequential file as defined by the standard.
Now the definition of what constitutes a record is not specified by the
standard. A compiler is free to consider there to be a final record even
without physical record terminator mark. That kind of decision is
compiler-dependent. Also, a compiler might choose to allow processing a
partial record as an extension. So in those senses, there is question as
to whether the file might or might not work. But those are questions
about the compiler's definition of records and about possible
extensions. I see nothing at all in the standard about partial records
in sequential files, so I don't know what question this is that you
might be referring to.
> Richard Maine <nos...@see.signature> wrote:
> > Both working would be fine - preferable even. My point was that with
> > stream, it ought to work per my understanding of the standard, but that
> > with sequential, the standard was mute so that the user could not count
> > on any specific behavior. Still, it is probably "nicest" for it to work
> > with sequential as well.
>
> I suppose I agree with "ought." As far as I know the standard doesn't
> require it to work in either case. Well, as with C, it depends on how you
> actually read the file. A program using stream could specifically look
> for the line terminator, and fail (in various ways) if it isn't there.
>
> As far as I know, IOSTAT still works, and can still have the IOSTAT_EOR
> value even with STREAM I/O. I suppose it could also be IOSTAT_EOF
> reading to the end of a line with no line terminator, or maybe a
> different, non-zero value.
You appear to be misreading the intention of my "ought". I meant it in
the sense of being required by the standard and thus ought to work
because compilers ought to adhere to the standard.
Stream I/O allows for partial records. That's not just something that
might be nice or might happen to be ok depending on the implementation.
It is explicitly specified in the Fortran standard. From f2003, 9.2.2.3,
the second (1) in the section.
"Some file storage units of the file may contain record markers; this
imposes a record structure on the file in addition to the stream
structure. There might or might not be a record marker at the end of
the file. If there is no record marker at the end of the file, the
final record is incomplete."
Yes, IOSTAT_EOR is allowed for stream, but that is irrelevant here
because IOSTAT_EOR is allowed only for non-advancing I/O. Lots of people
seem to get that one wrong. Non-advancing I/O is allowed for both stream
and sequential, but it is not being used in the case under discussion.
IOSTAT_EOF is indeed what you get for reading past the end of a stream
file, and that has nothing to do with whether there is a final record
marker or not. One doesn't really have to guess about these things.
There are things in the standard that are subtle and tricky to read, but
this isn't among them.
F2003, 9.10:
"An end-of-file considtion occurs in the following cases:
...
(3) When an attempt is made to read beyond the end of a stream file."
But I don't see that the code shown involes an attempt to read beyond
the end of the stream file. It reads to the end, but not beyond it.
The only minor caveat I can see is that the wording for list-directed
input doesn't look like it was redone to reflect partial records. I can
see that one might quibble about details relating to that. But that
doesn't sound to me like what you are looking at.