end-of-record versus end-of-file?

end-of-record versus end-of-file?

Post by karg » Mon, 12 Dec 2005 03:41:52



integer :: i = 1
open(11,status="replace",form="unformatted")
read(11,end=1008) i
1008 continue
read(11,end=1011) i
1011 continue
end

In the above, the first will hit an end-of-file condition
and execution will branch to statement label 1008. If I
understand 9.4.1.6(2) correctly, this read should update
the file position to after the endfile record. My question
concerns the second read. Is an end-of-record condition
appropriate. Sec. 9.4.3 suggests that end-of-file takes
precedence, and the second read should *silently* jump to
statement label 1011. Is a runtime warning a quality of
implementation question?

--
Steve
http://www.yqcomputer.com/ ~kargl/
 
 
 

end-of-record versus end-of-file?

Post by James Gile » Mon, 12 Dec 2005 05:48:30


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. Since you are still positioned at
the end of the file, the I/O statement should still report that.
As you noted, even with non-advancing I/O the endfile
condition takes precedent.

Notice that there usually isn't an endfile record and that
therefore the file can't be positioned after it. On some
unusual implementations, there may indeed be an
endfile record, but after that begins another file in the
same "multifile volume". In that case, the second read
would be into the additional data. The END=. or the
endfile condition returned as the IOSTAT value should
be used to correctly handle such possibilities. It the the
programmer's responsibility to use the indications recieved
correctly, not the language implementor's or the language
designer's.

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. Should a quality implementation give
increasingly surly messages each time I redundantly learn
that I'm still stuck at the file's end? Do I have to write my
code to deal with all those additional messages and/or
conditions?

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

 
 
 

end-of-record versus end-of-file?

Post by nospa » Mon, 12 Dec 2005 10:26:31


Agree.


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.


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.

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.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
 
 
 

end-of-record versus end-of-file?

Post by Dan Nagl » Mon, 12 Dec 2005 10:50:33

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.





--
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.
 
 
 

end-of-record versus end-of-file?

Post by Gary L. Sc » Mon, 12 Dec 2005 11:21:04

an Nagle wrote:


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.



--

Gary Scott
mailto: XXXX@XXXXX.COM

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
 
 
 

end-of-record versus end-of-file?

Post by karg » Mon, 12 Dec 2005 12:16:09

In article <yaHmf.142102$ XXXX@XXXXX.COM >,
"James Giles" < XXXX@XXXXX.COM > writes:


Thanks for confirm my interpretation.


The standard states otherwise. See 9.4.1.6(2). The first
READ will position the file to a point *after* the endfile
record.


That would violate the Fortran 95 standard. 9.4.1.6(2) states

If the file specified in the input statement is an external
file, it is positioned after the endfile record,

The question is what happens with the second READ above. You
are already beyond the endfile record. Is is accepted to essentially
do nothing and (re)position the file to a position after the
the endfile record, or is it an error?

--
Steve
http://www.yqcomputer.com/ ~kargl/
 
 
 

end-of-record versus end-of-file?

Post by Walter Spe » Mon, 12 Dec 2005 13:35:17


And I think the answer folks are trying to tell you is that "it depends".
Specifically on what kind of device the read statement is attempting to read.

As was mentioned, Mil-Std-1753 talks about this. In .5 it states:

"The processor must provide a facility that permits reading and
writing to continue past an endfile record on an unlabeled magnetic
tape sequential file. Reading past an endfile record is not
permitted if the READ statement does not contain and END= or
an IOSTAT= specifier. The processor may require execution of a
special subroutine or statement before it permits such reading or
writing."

Besides unlabeled magtape, there have been systems which have
supported "multi-file datasets" on disk. These attempted to
allow staging a tape to/from disk - EOF marks and all - in a
device-independant fashion. The CDC and early Cray systems
were popular examples of this capability.

Before you say "yes but those systems are things of the past",
there are still folks who attempt to read/write these sorts of
tape images. The ".tap" format that some folks currently use is
an example of this. (Though I don't know of any current Fortran
I/O library that directly supports reading/writing .tap files.)

Walt
 
 
 

end-of-record versus end-of-file?

Post by karg » Mon, 12 Dec 2005 14:49:47

n article < XXXX@XXXXX.COM >,
Walter Spector < XXXX@XXXXX.COM > writes:

The Fortran 95 standard has no concept of "kind of device".


Is Mil-Std-1753 an official part of the Fortran 95 standard?


I'm not going to say "yes but those systems are things of the past"
I'm going to say the Fortran 95 standard has no concept to magtape
or punch card or hard disk. It has the concept of endfile record.
The standard specifically states that

9.4.1.6 End-of-file branch
If an end-of-file condition (9.4.3) occurs and no error condition
(9.4.3) occurs during execution of an input statement that contains
an END= specifier
(1) Execution of the input statement terminates,
(2) If the file specified in the input statement is an external
file, it is positioned after the endfile record,
(3) If the input statement also contains an IOSTAT= specifier, the
variable specified becomes defined with a processor-dependent
negative integer value, and
(4) Execution continues with the statement specified in the END=
specifier.

There is no reference to magtape here.

The first read in the program I posted clearly falls under 9.4.1.6(2).
The remaining question is what does the second read do. If you read
9.4.3, we find

An end-of-file condition occurs in either of the following cases:
(1) When an endfile record is encountered during the reading of a
file connected for sequential access.
(2) When an attempt is made to read a record beyond the end of an
internal file.

Neither case applies! For (2), we are not reading an internal file.
For (1), we have already position the file beyond the endfile record
with the first READ. I'll accept your "it depends" statement in that
the behavior is no defined by the Standard, and so a Fortran processor
can do anything it wants.

--
Steve
http://troutmask.apl.washington.edu/~kargl/
 
 
 

end-of-record versus end-of-file?

Post by Brooks Mos » Mon, 12 Dec 2005 15:47:08


[...]

I think Richard answered that question in the second-to-last paragraph
of his post also in reply to James's post. To quote from his post:



I would thus suggest that it would be best to follow the apparent
consensus for what to do with this illegal condition, and have the
compiler report an error.

Your suggestion of "essentially doing nothing" in such a way that
reports EOFs ad infinitum is also defensible under the standard; it may
or may not fit some people's preferences with regards to quality of
implementation.

Personally, I think that since repeatedly supplying an EOF indication
can lead people to unknowingly write non-portable code that depends on
that behavior, it's better for the compiler to provide errors.

- Brooks


--
The "bmoses-nospam" address is valid; no unmunging needed.
 
 
 

end-of-record versus end-of-file?

Post by James Gile » Mon, 12 Dec 2005 16:15:01


...

I've already expressed my preference that EOF be reported
repeatedly in the (rather unlikely) scenario we're discussing.
The EOF will cause an error if END= or IOSTAT= was not
specified at all. And, why would a program specify those
options on the READ statement if it then disregarded the result?
But, if the standard actually requires ottherwise, thay won't be
the first place I disagree with the standard, nor the most important.
And certainly an implementation should comply with the standard.

(In my own defense: I've implemented Fortran I/O before,
and if the F77 standard had a requirement that the second
attempt to read an EOF should fail differently than the first,
I probably did it wrong. The environment I was on *did*
have "multifile volumes" though, and reading past one
EOF was actually possible in those cases. It still seems
pretty muddy to me. But, if there's a consensus as to the
proper interp, that's that.)

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
 
 
 

end-of-record versus end-of-file?

Post by Dan Nagl » Mon, 12 Dec 2005 19:22:15

Hello,



<snip a bunch>


Not per se. But implicit none, the bit intrinsics,
do while, enddo, and probably something I've forgotten are,
individually, part of the standard.

Mil Std 1753 was de facto supported by many, if not all, f77s.
It was a requirement for selling to DoD, or contractors
or subcontractors, which collectively is a significant market.
I wasn't on J3 at the time, but it seems the decision
was to support de facto extensions rather than 1753 as a whole.

<snip a bunch more>

--
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.
 
 
 

end-of-record versus end-of-file?

Post by Gordon San » Mon, 12 Dec 2005 23:07:30

n 2005-12-10 21:26:31 -0400, XXXX@XXXXX.COM (Richard Maine) said:


My recollection is that if you wanted to read the data records in the
next file of a multifile volume (tape) that you would read the
end-of-file to take the end exit and then execute an ENDFILE i/o command
before the read which would be in the next file. This was the rule for
that compiler on that operating system but it has a plausible logic if
one views the ENDFILE statement as confirming that you have finished with
that file and are intent on doing whatever makes sense after that. This
allowed you to reread the end-of-file record as often as you cared to
or accidently tried to but to get past it you had to do something special.





 
 
 

end-of-record versus end-of-file?

Post by Walter Spe » Tue, 13 Dec 2005 00:31:04


Almost all of Mil-Std-1753 was incorporated into Fortran-90. It was
published in 1978 and added the following to Fortran-77:

- END DO
- DO WHILE
- INCLUDE
- IMPLICIT NONE
- The unlabeled multifile magtape paragraph (.5)
- IOR, IAND, NOT, and IEOR intrinsics
- ISHFT, ISHFTC intrinsics
- IBITS, MVBITS intrinsics
- BTEST, IBSET, IBCLR intrinsics
- O and Z constants

As you can see, just about everything in it was incorporated into
Fortran-90 - except for .5. And as has been noted, most Fortran-77
environments did eventually support Mil-Std-1753. But I know of at
least one that did not.
> > I'm not going to say "yes but those systems are things of the past"> > I'm going to say the Fortran 95 standard has no concept to magtape> > or punch card or hard disk. It has the concept of endfile record.

It also has the concept of "backspacing". But that doesn't mean if you
issue one on a unit connected to /dev/tty, the users fingers are suddenly
going to get sucked back to the keyboard and untype the characters he just
typed. (As much fun as that would be to watch! :)
> > The remaining question is what does the second read do. If you read> > 9.4.3, we find> > > > An end-of-file condition occurs in either of the following cases:> > (1) When an endfile record is encountered during the reading of a> > file connected for sequential access.> > (2) When an attempt is made to read a record beyond the end of an> > internal file.> > > > Neither case applies! For (2), we are not reading an internal file.> > For (1), we have already position the file beyond the endfile record> > with the first READ. I'll accept your "it depends" statement in that> > the behavior is no defined by the Standard, and so a Fortran processor> > can do anything it wants.

And I'd lay odds that the case was intentionally left out - so as not to
generate an incompatibility with Mil-Std-1753 or other systems where
"multi-file datasets" were common.

Walt
 
 
 

end-of-record versus end-of-file?

Post by Ron Shepar » Tue, 13 Dec 2005 00:50:16

In article <r5Tmf.4502$hB6.2346@trnddc05>,



Unfortunately, there were many f77 compilers that did not support
the 1753 standard. The most common digression was in the support of
bit operations. There was the MIL standard which was supported by
DEC, IBM, FPS, and others, and there was the "other" set of
functions supported by f2c, Sun, Cray, CDC, and so on.

$.02 -Ron Shepard
 
 
 

end-of-record versus end-of-file?

Post by Gary L. Sc » Tue, 13 Dec 2005 01:51:12

rooks Moses wrote:
So your recommendation is to report an error that means essentially
"error -- attempt to read beyond end of file"? I think that is
acceptable, although I also think that reporting an EOF again is
acceptable. In most cases, you would be simply checking for
non-success. However, I'm slightly concerned with what would happen if
you had only and END= specifier and made such an attempt. I would think
it undesirable for the program to blow up and start printing error
messages to the console in that case (or silently terminate).

--

Gary Scott
mailto: XXXX@XXXXX.COM

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