Re: end-of-record versus end-of-file?

Dan Nagle wrote:

Hello,

Mil Std 1753 required a means of reading past an eof
to read a possible further file.  Some processors may have
some legacy behavior, at least when some switch is set,
to emulate that f77 behavior.

Richard Maine wrote:

James Giles <jamesgiles@xxxxxxxxxxxxxxxx> wrote:


End of record only applies to non-advancing I/O which
you are not doing here.  So, it is a condition that can't
arise in this code at all.




Agree.


Notice that there usually isn't an endfile record and that
therefore the file can't be positioned after it.




While there might not be a physical endfile record, the standard still
requires the compiler to make there appear to be one. While I swear that
I used to recall that compilers didn't typically do that, either my
recollection is faulty or things have changed. Either seems plausible. I
have been assured that current compilers do simulate the presence of an
endfile record, even if there isn't a physical one. In particular, this
comes up when backspacing after hitting and end-of-file. According to
the standard, if you want to read the last record in a file, one way to
do so would be to read until hitting and eof. Then backspace *TWICE*.
The first backspace goes back over the eof record (simulated or
physical), and the second one goes over the last data record. I have
been assured that you really do need two backspaces with current
compilers, just like the standard says, though I don't recall whether or
not I have personally tested.


Speaking for myself, I think the implementation should
report endfile conditions the same way each time I attempt
reading from a file that's positioned there.  I don't want to
field some separate error or (if present) IOSTAT value
that indicates that I've been informed of the endfile condition
more than once.




According to the standard, the eof indication is for reading the endfile
record, not for being after it. Trying to read when you are after it is
technically illegal. To my knowledge, most compilers give an error
status for such a read (except, presumably for the multifile file case,
but it has been an awful long time since I've actually seen one of
those; I used to deal with them all the time in the 70's and 80's, but I
don't think I've dealt with one in Fortran for a decade and a half). The
standard doesn't specify what happens with such code - just says it is
ilegal. It would thus be allowed for a compiler to do anything,
including the realistic options of reporting an error, reporting eof
again, or "normally" reading teh first record in the next file of a
multifile file.


On an OS that I used, there was an EOF marker and an EOT (end of tape) marker. The "real" end of file was the EOT marker. The "end of file" marker I guess would have been better termed a file segment marker ("end of segment"). This was a very useful concept, especially for real time data capture. It allowed you to start and stop the capture process and have conveniently identified file segments. Of course, it could have been done another way through data content, but then the native OS commands would not have been aware of it. That would have been very inconvenient.


But again, the main message here is that the eof condition doesn't
signify being "at" an end-of-file; it signifies than an eof record was
read. In my observation, compilers generally act like this implies,
whether there is a physical eof or not - subsequent read attempts give
an error indication.





--

Gary Scott
mailto:garyscott@xxxxxxx

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

Why are there two?  God only knows.


If you want to do the impossible, don't hire an expert because he knows it can't be done.

-- Henry Ford
.

Relevant Pages

  • Re: end-of-record versus end-of-file?
    ... Mil Std 1753 required a means of reading past an eof ... While there might not be a physical endfile record, the standard still ... I used to recall that compilers didn't typically do that, ... report endfile conditions the same way each time I attempt reading from a file that's positioned there. ...
    (comp.lang.fortran)
  • Re: reading exact contents of a line
    ... > Apparently there are a few compilers that violate the standard by ... > that more than one EOF value is allowed is that a few compilers happen ...
    (comp.lang.fortran)
  • Re: end-of-record versus end-of-file?
    ... While there might not be a physical endfile record, the standard still ... I used to recall that compilers didn't typically do that, ... do so would be to read until hitting and eof. ...
    (comp.lang.fortran)
  • Re: end-of-record versus end-of-file?
    ... While I swear that I used to recall that compilers didn't typically do that, either my recollection is faulty or things have changed. ... I have been assured that current compilers do simulate the presence of an endfile record, even if there isn't a physical one. ... this comes up when backspacing after hitting and end-of-file. ... According to the standard, if you want to read the last record in a file, one way to do so would be to read until hitting and eof. ...
    (comp.lang.fortran)
  • Re: problem using FILE pointer
    ... feofonly signals that an EOF has been ... Before that the following fread (or getc etc.) statement ... encounter EOF. ... Only for modern compilers. ...
    (comp.arch.embedded)