Home > Archive > Fortran > December 2005 > end-of-record versus end-of-file?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
end-of-record versus end-of-file?
|
|
| Steven G. Kargl 2005-12-10, 7:14 pm |
| 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://troutmask.apl.washington.edu/~kargl/
| |
| James Giles 2005-12-10, 7:14 pm |
| Steven G. Kargl wrote:
> 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?
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
| |
| Richard Maine 2005-12-10, 10:10 pm |
| James Giles <jamesgiles@worldnet.att.net> 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.
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
| |
| Dan Nagle 2005-12-10, 10:10 pm |
| 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@worldnet.att.net> wrote:
>
>
>
>
> 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.
>
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
| Gary L. Scott 2005-12-10, 10:10 pm |
| 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:
>
>
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:garyscott@ev1.net
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
| |
| Steven G. Kargl 2005-12-10, 10:10 pm |
| In article <yaHmf.142102$qk4.71983@bgtnsc05-news.ops.worldnet.att.net>,
"James Giles" <jamesgiles@worldnet.att.net> writes:
> Steven G. Kargl 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.
Thanks for confirm my interpretation.
> Since you are still positioned at the end of the file, the I/O
> statement should still report that.
The standard states otherwise. See 9.4.1.6(2). The first
READ will position the file to a point *after* the endfile
record.
> Notice that there usually isn't an endfile record and that
> therefore the file can't be positioned after it.
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://troutmask.apl.washington.edu/~kargl/
| |
| Walter Spector 2005-12-11, 4:10 am |
| "Steven G. Kargl" wrote:
> ...
> 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?
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 §2.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
| |
| Steven G. Kargl 2005-12-11, 4:10 am |
| In article <439BAC46.64A1B4F4@earthlink.net>,
Walter Spector <w6ws_xthisoutx@earthlink.net> writes:
> "Steven G. Kargl" wrote:
>
> 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.
The Fortran 95 standard has no concept of "kind of device".
> As was mentioned, Mil-Std-1753 talks about this.
Is Mil-Std-1753 an official part of the Fortran 95 standard?
> In §2.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.)
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/
| |
| Brooks Moses 2005-12-11, 4:10 am |
| Steven G. Kargl wrote:
> In article <yaHmf.142102$qk4.71983@bgtnsc05-news.ops.worldnet.att.net>,
> "James Giles" <jamesgiles@worldnet.att.net> writes:
>
> The standard states otherwise. See 9.4.1.6(2). The first
> READ will position the file to a point *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?
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:
Richard Maine wrote:
> 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.
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.
| |
| James Giles 2005-12-11, 4:10 am |
| Brooks Moses wrote:
....
> 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.
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
| |
| Dan Nagle 2005-12-11, 8:11 am |
| Hello,
Steven G. Kargl wrote:
<snip a bunch>
> Is Mil-Std-1753 an official part of the Fortran 95 standard?
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.
| |
| Gordon Sande 2005-12-11, 8:11 am |
| On 2005-12-10 21:26:31 -0400, nospam@see.signature (Richard Maine) said:
> James Giles <jamesgiles@worldnet.att.net> wrote:
>
>
> 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.
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.
| |
| Walter Spector 2005-12-11, 7:16 pm |
| "Steven G. Kargl" wrote:
> ...
> Is Mil-Std-1753 an official part of the Fortran 95 standard?
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 (§2.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 §2.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
| |
| Ron Shepard 2005-12-11, 7:16 pm |
| In article <r5Tmf.4502$hB6.2346@trnddc05>,
Dan Nagle <dannagle@verizon.net> wrote:
> Mil Std 1753 was de facto supported by many, if not all, f77s.
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
| |
| Gary L. Scott 2005-12-11, 7:16 pm |
| Brooks Moses wrote:
> Steven G. Kargl wrote:
>
>
> [...]
>
>
>
> 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:
>
> Richard Maine wrote:
>
>
>
> 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
>
>
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:garyscott@ev1.net
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
| |
| Gary L. Scott 2005-12-11, 7:16 pm |
| Walter Spector wrote:
> "Steven G. Kargl" wrote:
>=20
>=20
>=20
> Almost all of Mil-Std-1753 was incorporated into Fortran-90. It was
> published in 1978 and added the following to Fortran-77:
>=20
> - END DO
> - DO WHILE
> - INCLUDE
> - IMPLICIT NONE
> - The unlabeled multifile magtape paragraph (=A72.5)
> - IOR, IAND, NOT, and IEOR intrinsics
> - ISHFT, ISHFTC intrinsics
> - IBITS, MVBITS intrinsics
> - BTEST, IBSET, IBCLR intrinsics
> - O and Z constants
>=20
> As you can see, just about everything in it was incorporated into
> Fortran-90 - except for =A72.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.
Some supported them, but under a different name...the "Purdue Extensions"=
=2E
>=20
>=20
>=20
>=20
> 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 sudden=
ly
> going to get sucked back to the keyboard and untype the characters he j=
ust
> typed. (As much fun as that would be to watch! :)
>=20
>=20
a[color=darkred]
an[color=darkred]
>=20
>=20
> And I'd lay odds that the case was intentionally left out - so as not t=
o
> generate an incompatibility with Mil-Std-1753 or other systems where
> "multi-file datasets" were common.
>=20
> Walt
--=20
Gary Scott
mailto:garyscott@ev1.net
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=20
it can't be done.
-- Henry Ford
| |
| Richard Maine 2005-12-11, 7:16 pm |
| Gordon Sande <g.sande@worldnet.att.net> wrote:
> 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.
While this might be true ( I don't recall, and you might have been on a
different system anyway), it doesn't sound sensible, because that would
have another prefectly sensible meaning - the one defined by the
standard. At least currently (I haven't gone back to check old standards
for consistency), the ENDFILE statement *WRITES* an end-of-file record.
Thus I would expect to use it when writing such a tape, but if you are
reading a tape, then you sure don't want to write anything to it for
multiple reasons. I suppose it is possible that endfile could have been
special-case to have multiple meanings, but I frankly doubt it. I'd
guess it more likely that you are confusing the reading and writing
processes.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| Richard Maine 2005-12-11, 7:17 pm |
| Walter Spector <w6ws_xthisoutx@earthlink.net> wrote:
> 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 I/O chapter in the standard has a *huge* loophole, which says that
you (the programmer) aren't allowed to do anything that a particular
device doesn't support. Backspacing a terminal is a classic example of
this. If the standard allowed reading after an eof, that would be
another. The loophole is so large that it is technically possible to
have a standard-conforming compiler with no I/O, if you claim that there
are no devices capable of any of the Fortran I/O operations (which isn't
actually completely unrealistic for embedded applications... and there
has been at least oen Fortran compiler that didn't have I/O - the
compiler for the FPS coprocessor).
[on reading after hitting an eof]
>
> 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.
Do note that although it is true that the behavior is undefined in the
Fortran standard, it doesn't say it in those words. What the standard
says is that it is illegal (well, not standard-conforming). The
"undefined behavior" bit is just what you get when you do nonstandard
things that aren't required to be diagnosed.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| Walter Spector 2005-12-11, 7:17 pm |
| "Gary L. Scott" wrote:
>
> Walter Spector wrote:
>
> Some supported them, but under a different name...the "Purdue Extensions".
True - in the case of much of the bit manipulation stuff. It was part of
something called IRTF (Industrial Real-time Fortran) - which originated with
some workshops held at Purdue.
The shift intrinsics in IRTF were a tad different than Mil-Std-1753 though.
And IRTF included a whole set of subroutine calls for parallel threads
and also for real-time device I/O. None of which was included in -1753.
Now that you mentioned IRTF, I need make sure I still know where
my copy of it is...
Walt
| |
| Richard Maine 2005-12-11, 7:17 pm |
| James Giles <jamesgiles@worldnet.att.net> wrote:
> 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?
The issues I've seen involve users who specify IOSTAT and then handle it
in a way that depends on whether it got an eof or error indication. I
know I've seen programs (including mine... ahem :-() infinite loop
because of mishandling this, though I forget the details, and any of
several are possible. For example...
1. You are expecting an eof and reading until you hit one. You get an
error instead. I forget why one continued after an error. Maybe it was
just plain overlooking the possibility of getting an error. Anyway, for
whatever reason, I *KNOW* I've seen this one happen.
2. I've also seen code that hit an eof, then later, in another part of
the code retried a read, expecting to get an eof again, and failed. What
I don't recall is whether this code had worked on some platforms and
failed when porting, or whether this was code that the user was trying
to get working for the first time.
I don't particularly claim these are things users ought to do - more
like coding errors, but they are coding errors I've seen.
I'd mostly advocate the compilers give an error return (unless they
happen to implement multi-file files). The two reasons are
1. It is common practice. The other compilers today pretty much all do,
so being different won't help much, no mater how good the intent.
2. Althoug the standard doesn't require it, I think that giving an error
return is the behavior most intuitively consistent with something that
the standard says is illegal (again, unless multi-file files are
implemented).
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| Gordon Sande 2005-12-11, 7:17 pm |
| On 2005-12-11 13:27:21 -0400, nospam@see.signature (Richard Maine) said:
> Gordon Sande <g.sande@worldnet.att.net> wrote:
>
>
> While this might be true ( I don't recall, and you might have been on a
> different system anyway), it doesn't sound sensible, because that would
> have another prefectly sensible meaning - the one defined by the
> standard. At least currently (I haven't gone back to check old standards
> for consistency), the ENDFILE statement *WRITES* an end-of-file record.
>
> Thus I would expect to use it when writing such a tape, but if you are
> reading a tape, then you sure don't want to write anything to it for
> multiple reasons. I suppose it is possible that endfile could have been
> special-case to have multiple meanings, but I frankly doubt it. I'd
> guess it more likely that you are confusing the reading and writing
> processes.
My recollection is that ENDFILE on READing had this curious effect on
the Fortran IV on IBM360s, or maybe the Fortran IV on IBSYS on
IBM/7090, before there was any OPEN statement available. One normally
thinks of ENDFILE as writing the end-of-file record to tape or
truncating the file on disk. If the unit is open for reading then
the writing should not be possible. It struck me as an ingeneous hack
to deal with the problem of skipping over the end-of-file record on
a multifile tape without having to introduce either a new statement
or another support subroutine. I also recall that there was an additional
layer of convention with multiple end-of-file records indicating that
the logical end-of-tape had been reached without having to spin down
the tape to the hardware reflective markers, all of which was handled
by the run time package.
It is one of those things that fully deserves to stay lost in the mists
of history.
| |
| James Giles 2005-12-11, 7:17 pm |
| Richard Maine wrote:
....
> 1. You are expecting an eof and reading until you hit one. You get an
> error instead. I forget why one continued after an error. Maybe it was
> just plain overlooking the possibility of getting an error. Anyway,
> for whatever reason, I *KNOW* I've seen this one happen.
Well, I see your point. But it also makes my point. If the
code (for whatever reason) is disregarding errors and
continuing to try to read, then won't it also disregard the
error that means "you tried to read at EOF twice"? So,
classifying the second READ attempt an error wouldn't
help. (Of course, if it were expecting an EOF it would have
stopped when it got the first one.)
> 2. I've also seen code that hit an eof, then later, in another part of
> the code retried a read, expecting to get an eof again, and failed.
> What I don't recall is whether this code had worked on some platforms
> and failed when porting, or whether this was code that the user was
> trying to get working for the first time.
So, my preference that the I/O consistently continue to report EOF
at further READ attempts would have worked for this code. The
other part of the code that expected to get an EOF again would have
got what it expected. On the other hand, if it had a test for EOF
(like END= on the READ statement), but no test for error conditions,
the program would terminate if the second attempt to read EOF is
classified as an error. It seems to me most would regard that
as broken behavior on the part of the implementation.
I see what you're getting at. There probably are (rare) situations that
can lead to problems with my prefered rule. The fact that you have
difficulty contriving one makes it clear that it's not sufficiently
common to justify increasing the complexity of the language (in this
vcase by having the same operation in the same situation do different
things). As my signature quote implies, I prefer simplicity in design.
--
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
| |
| Gary L. Scott 2005-12-11, 7:17 pm |
| James Giles wrote:
> Richard Maine wrote:
> ...
>
>
>
> Well, I see your point. But it also makes my point. If the
> code (for whatever reason) is disregarding errors and
> continuing to try to read, then won't it also disregard the
> error that means "you tried to read at EOF twice"? So,
> classifying the second READ attempt an error wouldn't
> help. (Of course, if it were expecting an EOF it would have
> stopped when it got the first one.)
>
>
>
>
> So, my preference that the I/O consistently continue to report EOF
> at further READ attempts would have worked for this code. The
> other part of the code that expected to get an EOF again would have
> got what it expected. On the other hand, if it had a test for EOF
> (like END= on the READ statement), but no test for error conditions,
> the program would terminate if the second attempt to read EOF is
> classified as an error. It seems to me most would regard that
> as broken behavior on the part of the implementation.
>
> I see what you're getting at. There probably are (rare) situations that
> can lead to problems with my prefered rule. The fact that you have
> difficulty contriving one makes it clear that it's not sufficiently
> common to justify increasing the complexity of the language (in this
> vcase by having the same operation in the same situation do different
> things). As my signature quote implies, I prefer simplicity in design.
>
I think I want it to provide an "end of tape" equivalent to formally
accomodate the multi-segment concept. Or simply add an "end of segment"
concept explicitly to the standard and resolve the issue more
thoroughly (end of file would be quivalent to EOT in older multifile
systems). A one-segment file with no EOS marker might return only an
EOF status or an EOS status (if an ENDSEGMENT is written) then an EOF
status on next read. I find the multi-file concept to be useful.
Adding formal support would clarify this area of behavior.
--
Gary Scott
mailto:garyscott@ev1.net
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
| |
| Richard Maine 2005-12-11, 7:17 pm |
| Gordon Sande <g.sande@worldnet.att.net> wrote:
> My recollection is that ENDFILE on READing had this curious effect on
> the Fortran IV on IBM360s, or maybe the Fortran IV on IBSYS on
> IBM/7090, before there was any OPEN statement available.
But without an OPEN statement, how was it even defined whether you were
reading or writing? After all, it is perfectly valid, and even something
People have probably done, to read to some point in the tape, then write
and endfile record there. In fact, that is one of the few actual uses
for the ENDFILE statement today on disk files - to truncate the file.
0
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| Gordon Sande 2005-12-11, 7:17 pm |
| On 2005-12-11 16:33:38 -0400, nospam@see.signature (Richard Maine) said:
> Gordon Sande <g.sande@worldnet.att.net> wrote:
>
>
> But without an OPEN statement, how was it even defined whether you were
> reading or writing? After all, it is perfectly valid, and even something
> People have probably done, to read to some point in the tape, then write
> and endfile record there. In fact, that is one of the few actual uses
> for the ENDFILE statement today on disk files - to truncate the file.
> 0
That you were reading the tape is usually considered fairly obvious
by the fact that the previous i/o command executed was a READ. Then
the state would be "end-of-file encountered while reading". At that point
the ancient system, as I recall it, was willing to treat an ENDFILE
statement as a request to position after the end-of-file so that the
records in the next file of the multifile volume could be read.
This is primarily an indication that the ancients had a degree of
ingenuity in dealing with the foibles of the systems they were on.
One could have a philosophical debate whether the ENDFILE was a read
or a write as it acts to logically remove the file just read.
If you have just read an end-of-file then writing one to truncate the
dataset has little semantic meaning unlike the situation of reading
a record that is not an end-of-file and then writing an end-of-file
to keep others, or even yourself later, from reading past the point.
All told, a curious hack to deal with a curious situation. Not to be
recomended for future use.
| |
| Brooks Moses 2005-12-11, 7:17 pm |
| Gary L. Scott wrote:
> Brooks 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.
Essentially, yes. Both appear to me to be acceptable with regards to
the standard; I would personally recommend the first.
> 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).
Having just read Steve Maguire's _Writing Solid Code_ last night, I
think I'd disagree. His position (which I agree with) would likely be
that it's desirable in such a case to report an error, because the
chances are high that such an attempt is due to a bug in the code or
algorithm. Silently repeating the EOF condition increases the chance
that such a bug will lurk unnoticed.
- Brooks
--
The "bmoses-nospam" address is valid; no unmunging needed.
| |
| Klaus Wacker 2005-12-12, 4:13 am |
| Gordon Sande <g.sande@worldnet.att.net> wrote:
>
> 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.
>
This is opposite to my recollection. ENDFILE writes an end-of-file
record. Once you wrote something on a tape, there was no way one could
continue reading from that tape without a previous backspace or rewind.
--
Klaus Wacker wacker@Physik.Uni-Dortmund.DE
Experimentelle Physik V http://www.physik.uni-dortmund.de/~wacker
Universitaet Dortmund Tel.: +49 231 755 3587
D-44221 Dortmund Fax: +49 231 755 4547
| |
| glen herrmannsfeldt 2005-12-19, 3:58 am |
| Richard Maine wrote:
> Gordon Sande <g.sande@worldnet.att.net> wrote:
For OS/360, an open to unit n opens DDNAME FTnnF001, where nn is
the two digit unit number. A DDNAME is associated with a disk file,
tape file, sysin or sysout file through a DD statement. I believe
then after ENDFILE it goes to FTnnF002, and successively
higher up to FTnnF999. To write a multiple file tape requires
one DD statement for each file.
[color=darkred]
> But without an OPEN statement, how was it even defined whether you were
> reading or writing? After all, it is perfectly valid, and even something
> People have probably done, to read to some point in the tape, then write
> and endfile record there. In fact, that is one of the few actual uses
> for the ENDFILE statement today on disk files - to truncate the file.
> 0
There were some complications related to this for OS/360. OS/360, and
probably many other OS, opens files for INOUT. There are some
conditions where this doesn't work and a JCL parameter LABEL=(,,,IN)
is needed to force it to open for input only. Reading a member of a PDS
might be one of them.
-- glen
|
|
|
|
|