Home > Archive > Fortran > September 2006 > end-of-file during read using unformatted reading
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-file during read using unformatted reading
|
|
|
| Hi
I have question about the following program:
program main
a=1.0
write(88)a
open(88,file='fort.88',status='old',form='unformatted')
read(88)a
print *,a
stop
end
I use CVF6.6C. The error message shows "end-of-file during read".
If I replace the above as :
read(88,end=1)a
1 print *,a
then it's ok. Why?
Mike
| |
| glen herrmannsfeldt 2006-09-13, 4:01 am |
| Mike wrote:
(snip)
> a=1.0
> write(88)a
> open(88,file='fort.88',status='old',form='unformatted')
> read(88)a
> print *,a
> stop
> end
> I use CVF6.6C. The error message shows "end-of-file during read".
> If I replace the above as :
> read(88,end=1)a
> 1 print *,a
> then it's ok. Why?
What do you mean by ok? Do you mean that a has the right value?
I believe if the END= exit is taken that you can't rely on any
of the list items as being correct. Otherwise, it might be that
there is something wrong in the file after a, such that a is stored
before it is noticed. You should correct the problem.
It might be that you should do a REWIND 88 or ENDFILE 88 or
even CLOSE(88) before reopening it. I believe with REWIND it
is ready to read without another OPEN.
-- glen
| |
|
|
glen herrmannsfeldt wrote:
> Mike wrote:
> (snip)
>
>
>
>
>
> What do you mean by ok? Do you mean that a has the right value?
Yes. And, no error message appears.
>
> I believe if the END= exit is taken that you can't rely on any
> of the list items as being correct. Otherwise, it might be that
> there is something wrong in the file after a, such that a is stored
> before it is noticed. You should correct the problem.
>
> It might be that you should do a REWIND 88 or ENDFILE 88 or
> even CLOSE(88) before reopening it. I believe with REWIND it
> is ready to read without another OPEN.
>
> -- glen
Yes. REWIND(88) or CLOSE(88) will be OK. But ENDFILE(88) still have
the same error message.
Thank you.
Mike
| |
| Richard Maine 2006-09-13, 4:01 am |
| Mike <acout@yam.com> wrote:
> glen herrmannsfeldt wrote:
> Yes. And, no error message appears.
There shouldn't be an error message. You've basically told it to ignore
the problem. Just because the right value appears to print, that doesn't
mean the code is actually working correctly. If you hit an end-of-file,
as you did, then it is invalid to print (or otherwise reference) the
variable "a". It might or might not happen to print what you'd expect,
depending on the compiler, the phase of the moon, or anything else. The
code is just invalid, and in a way that the comipler is not required to
diagnose because "a" is technically "undefined." Some compilers might
give you an error message; others won't.
Indeed, what is probably happening is that there is no value read for
"a" at all, but the previous value is unchanged. That is not behavior
guaranteed by the standard, but I'd guess that's what your particular
compiler must be doing if the value prints as you expect. It is not
plausible that the value would be read from the file.
> Yes. REWIND(88) or CLOSE(88) will be OK. But ENDFILE(88) still have
> the same error message.
That's expected. The endfile basically does nothing here (or pretty much
anywhere; it is a pretty useless statement in today's environments). I
would not have suggested using it.
The answer to your question about why you are getting an endfile is that
the OPEN statement basically does nothing here. When you OPEN a unit
with the same file that it is already attached to, that OPEN does not
reposition the file or anything like that. In fact, it does not close
and reopen the file. Instead it just changes the properties of the
current connection... except that you haven't specified any changes, so
it essentially does nothing. That's a rather obscure usage of OPEN.
Unless you actually intend to change the properties of an existing
connection, you should normally close the file first.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| glen herrmannsfeldt 2006-09-13, 4:01 am |
| Richard Maine wrote:
(snip)
> The answer to your question about why you are getting an endfile is that
> the OPEN statement basically does nothing here. When you OPEN a unit
> with the same file that it is already attached to, that OPEN does not
> reposition the file or anything like that. In fact, it does not close
> and reopen the file. Instead it just changes the properties of the
> current connection... except that you haven't specified any changes, so
> it essentially does nothing. That's a rather obscure usage of OPEN.
> Unless you actually intend to change the properties of an existing
> connection, you should normally close the file first.
Since there is no OPEN statement before the first WRITE, it depends
on 'fort.88' being the default file name. It isn't so obvious to
me that an OPEN statement specifying that name doesn't change
anything. That does seem likely what it is doing, though.
-- glen
| |
| Terence 2006-09-13, 7:02 pm |
| > I have question about the following program:
> program main
>
> a=1.0
> write(88)a
> open(88,file='fort.88',status='old',form='unformatted')
> read(88)a
> print *,a
> stop
> end
>
You have a WRITE to unit 88 before you opened it so CVF will use a
default definition of the file opeartions to be used. (You should have
oopened the file, writen, then rewound the file before reading)
Then you opened the file and made a read unformatted operation without
having any indication of how much data you want to read (or write) so
you got an end-of-file after the last character that the read expected.
You see, "a" is a real variable, but you haven't defined the size of it
nor the way to writting it or what to expect when reading it, and when
you wrote to an unopened default file, I suspect "a" it was wriiten as
an ascii string.
| |
| Terence 2006-09-13, 7:02 pm |
| I should have said that when you wrote to unit 88, if it worked at all,
it was opened by a previous OPEN statemen, or else opened by the the
CVF default.
After which, you had an OPEN file operation present on a file which was
not closed.
The standard says that if you try to reopen an already-open file, the
statement is ignored and the file remains open in the form it was
previously opened.
So your OPEN statement after the WRITE operation was ignored and your
next READ statement then read the file from the point after having
written it, so you got an immediate end-of-file signal.
As I pointed out, you need a REWIND statement after, or instead of,
the OPEN file statement the you have. The real variable would have been
read back in the same way it was written and not an ascii string as I
first thought was the cause.
| |
| Richard E Maine 2006-09-13, 7:02 pm |
| Terence <tbwright@cantv.net> wrote:
> You see, "a" is a real variable, but you haven't defined the size of it
> nor the way to writting it or what to expect when reading it, and when
> you wrote to an unopened default file, I suspect "a" it was wriiten as
> an ascii string.
That is pretty much just all incorrect. I don't think I'll go into
point-by-point detail. Note, in particular, that the write in question
is an unformatted write, which is syntactically determinable without
reference to any OPEN statement. You will not get translation to/from
ascii or any other text form. There is no needed definition of the
"size" of "a" (whatever that means) or any of the other stuff mentioned
above.
The *ONLY* thing wrong with the code in question is that the reopen
doesn't rewind, so the code needed to either close or rewind the file.
(And the code assumed a preconnection of unit 88 to fort.88, but that's
a compiler dependency rather than an error.)
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
|
|
> Indeed, what is probably happening is that there is no value read for
> "a" at all, but the previous value is unchanged.
Oh. :) yes. Thanks for the reminding.
> The answer to your question about why you are getting an endfile is that
> the OPEN statement basically does nothing here. When you OPEN a unit
> with the same file that it is already attached to, that OPEN does not
> reposition the file or anything like that.
Now I understand.
Mike
| |
| Dick Hendrickson 2006-09-14, 10:00 pm |
|
Terence wrote:
> I should have said that when you wrote to unit 88, if it worked at all,
> it was opened by a previous OPEN statemen, or else opened by the the
> CVF default.
> After which, you had an OPEN file operation present on a file which was
> not closed.
>
> The standard says that if you try to reopen an already-open file, the
> statement is ignored and the file remains open in the form it was
> previously opened.
No, an OPEN to a unit that is already connected to a file is
allowed. It isn't ignored. If the file specified is the
same as the currently connected file, then the "changeable"
modes can be changed. If the file is different from the
currently connected file, it acts as if there was a CLOSE
for the currently connected file and then the new file is
connected. Section 9.4.5 in F2003 goes through all of
the gory details, they are essentially unchanged from F95.
Dick Hendrickson
>
> So your OPEN statement after the WRITE operation was ignored and your
> next READ statement then read the file from the point after having
> written it, so you got an immediate end-of-file signal.
>
> As I pointed out, you need a REWIND statement after, or instead of,
> the OPEN file statement the you have. The real variable would have been
> read back in the same way it was written and not an ascii string as I
> first thought was the cause.
>
| |
| Terence 2006-09-14, 10:00 pm |
| Richard Maine always tries to find fault with anybody else's
contributions.
Note that the original question specified CVF version 6.6c, which is an
F77/F90 compiler, not F95 or 2003 NET conforming as later notes seem to
to refer.
I had accurately paraphrased from two of our Compaq manuals for that
compiler.
Here is the original text, page 13-26:
"If an OPEN statement is executed for a unit that already exists, the
following occurs:
If FILE is not specified, or FILE specifies the same file name, that
appeared in a previous OPEN statement, the current file remains
connected.
(... details on parameters changable..)
Other OPEN specifier values cannot be changed and the file position is
unaffected"
If FILE specifies a different filename, the previous file is closed
and the new file connected to the unit."
SO, as I said, another open made to a still-open file of the same name
is ignored and the file position remains the same - giving the EOF on
the next read in the example program!.
You CAN open the same named file using two different unit numbers and
access parameters and the program will treat them as two different
files as far as valid positions indicates. A very useful technique in
forward-looking while processing data.
I was NOT on the original Fortran team at IBM, but I WAS part of the
Fortran team for IBM in the UK in 1961-1964 and used it ever since, and
taught it as IBM lecturer at London University in computer scence. I
know what works for me and I esperienced a similer double-open once by
having different routes though code to get to the appropriate OPEN's
for the files in question (Very, very big program). I contribute from a
long knowledge of Fortran up to and including F77; but I rarely take
part in F90/F95 problems unless I have had the same problem using F90.
| |
| Richard Maine 2006-09-14, 10:00 pm |
| Terence <tbwright@cantv.net> wrote:
> Richard Maine always tries to find fault with anybody else's
> contributions.
No comment.
> Note that the original question specified CVF version 6.6c, which is an
> F77/F90 compiler, not F95 or 2003 NET
I have no idea what "f2003 NET" would mean. Whatever it might be, it
certainly isn't anything that I ever comment about. In any case, none of
the issues I mentioned have anything to do with anything that changed
after f77 when the OPEN statement was introduced. The material that I
disagreed with was about writing without an OPEN; that stuff hasn't
changed since at least Fortran II days, if ever, but my experience
doesn't go back any earlier than Fortran II.
> [lots of stuff about re-open elided]
I tend to have trouble telling what you are referring to because you
typically don't quote anything or give much other direct hint about what
you are replying to, but the *ONLY* thing that I made any comment at all
about in your posting had nothing to do with the reopen. The following
is an exact cut&paste of the material that I said I disagreed with.
> You see, "a" is a real variable, but you haven't defined the size of it
> nor the way to writting it or what to expect when reading it, and when
> you wrote to an unopened default file, I suspect "a" it was wriiten as
> an ascii string.
Nothing at all relating to reopen or indeed any open at all there. Quite
the opposite - it is about what happend when you write without an open.
As far as I can tell, you must be having as hard a time figuring out
what I am talking about as I am having figuring out what you are talking
about. It looks like a complete nonsequitur to me.
I will not continue this "conversation" (if that term accurately
described 2 people posting, with neither having any idea what the other
is talking about). My only goal in posting in the first place was to
make sure that the OP was not mislead. The OP's problem having been
solved, I see no further benefit in the "conversation".
> You CAN open the same named file using two different unit numbers
The standard explicitly says otherwise - that would be all versions of
the standard that have an OPEN statement. It being illegal code, the
result depends on the compiler. Different compilers andoperating systems
DO handle this differently; I've seen it. Not that this has any
observable relationship with the OP's question or anything else
previously mentioned in the thread. I'm lost again about why this is
even mentioned.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| AeroSpace Ed 2006-09-15, 8:01 am |
| Terence wrote:
> Richard Maine always tries to find fault with anybody else's
> contributions.
You are sorely mistaken here. I find that Richard's posts are the most
informative and most detailed and are generally 'right on'. He is very
good at explaining 'nuances' and why they are so important to get right if
we want to arrive at a better understanding of each other's questions and
problems.
I find it troubling when others spout outdated FORTRAN lore and superstition
AS fact.
Please go back and read Richard's post and the quote that he referenced from
your post. Which is:
Terence <tbwright@cantv.net> wrote:
> You see, "a" is a real variable, but you haven't defined the size of it
> nor the way to writting it or what to expect when reading it, and when
> you wrote to an unopened default file, I suspect "a" it was wriiten as
> an ascii string.
Richard responded with, "That is pretty much just all incorrect."
I agree. It's dangerously wrong.
Ed
| |
| Steve Lionel 2006-09-15, 8:01 am |
| Terence wrote:
> Richard Maine always tries to find fault with anybody else's
> contributions.
> Note that the original question specified CVF version 6.6c, which is an
> F77/F90 compiler, not F95 or 2003 NET conforming as later notes seem to
> to refer.
Sorry, that is not correct. CVF 6.6C is fully compliant with Fortran
95.
> I had accurately paraphrased from two of our Compaq manuals for that
> compiler.
> Here is the original text, page 13-26:
[snip]
>
> SO, as I said, another open made to a still-open file of the same name
> is ignored and the file position remains the same - giving the EOF on
> the next read in the example program!.
You are quoting the text for the feature "OPEN on a connected unit",
which first made its appearance in Fortran 77 and has been pretty much
unchanged since. Your "as I said" misrepresents the text you quoted.
> You CAN open the same named file using two different unit numbers and
> access parameters and the program will treat them as two different
> files as far as valid positions indicates. A very useful technique in
> forward-looking while processing data.
That CVF allows you to open the same file on two different units is an
extension - a program which does that is non-standard. It also has
nothing to do with the text you cited which deals with opening a file
on the SAME unit number when that unit is already opened. What happens
then depends on whether or not the file specified is the same as the
one already opened. The program in Mike's original post does that and
the behavior has been correctly explained. When you introduce
different unit numbers, that's another thing entirely.
> I was NOT on the original Fortran team at IBM, but I WAS part of the
> Fortran team for IBM in the UK in 1961-1964 and used it ever since, and
> taught it as IBM lecturer at London University in computer scence. I
I WAS on the DEC/Compaq Fortran team from 1978-1980 and 1988-2003 and
implemented "OPEN on a connected unit" for VAX FORTRAN back in 1979. I
know what our compilers did and didn't do in this area. I'll tell you
that Richard Maine and Dick Hendrickson are giving you correct
information and that you would do well to respect their expertise in
the area of Fortran, as I certainly do. You might also want to brush up
on your Fortran language skills so that you are conversant with recent
standards.
Steve Lionel
Developer Products Division
Intel Corporation
| |
| Phillip Helbig---remove CLOTHES to reply 2006-09-16, 7:02 pm |
| In article <1158297010.552833.71950@h48g2000cwc.googlegroups.com>,
"Steve Lionel" <steve.lionel@intel.com> writes:
> I WAS on the DEC/Compaq Fortran team from 1978-1980 and 1988-2003 and
> implemented "OPEN on a connected unit" for VAX FORTRAN back in 1979.
What were you doing 1981--1987?
| |
| Terence 2006-09-16, 7:02 pm |
| I accept that Steve says the CVF6.6c is F95 compliant. My manual refers
to the compiler as delivered, refers to it containing F90 from Digital
in 1994. So I assumed an F90 capability limit. One way or another
(updates?), what we have now seems to be also F95 although we use it
(them) with only F77 and F90 source code.
My original postings was being prepared on-line with difficulty, (can't
they increase the font size? One half of the screen is blank!) then in
exasperation I cut and pasted bits to an editor (for vision and spell
checking) and a big remaining part escaped when the mouse passed over
the Post button when I wanted to see what Preview would do for me (see
how many typos were left). I didn't see what what got posted before
then sending (you have to get off, then on again) what I considered to
be a correct analysis in a follow-on.
Yes, the first posting reads badly.
I had written to suggest that the OP had already output an ascii string
(obviously with format) since the file was obviously opened previously;
and this is why he had something to read which gave an error; then I
saw the real problem solution and addressed it.
I stand by my analysis that (Dick misunderstood what I had written)
that the open statement was ignored and the next read operation gave an
end-file. Then I needed to quote the actual text from the manual I had
ALREADY read first! Which was still challenged.[color=darkred]
Still Yes!
But yes, you can change some very minor options with later new OPENs on
an open file on the same unit (on F90/95, not on our F77), but that
wasn't the point.
A new comment. Most of the problems with code, that I have seen
presented on this Forum, were caused by trying to use complicated
F90/F95 style programming, most especially with the form of the I/O
statements.
It's too easy to write something that compiles because of the defaults
and multitude of options, but doesn't do what was expected.
If you get F77 code wrong you know it fast! And fix it fast!
I don't see the need for most everything available beyond F77 coding
except the variable checking in interfaces. And I suggest users solve
external report problems by first preparing output to internally
formatted strings and writing these.
Sure, criticise errors of fact, but not personal techniques and
preferences.
I once suggested writing F77 code to get it working then change it to
F90 for future maintenance. It's economical.
Steve says that having the same file open on two unit numbers is
outside the standard. I believe what he says. But it didn't use to be
and it still works (as he accepts). To get around the standard now, all
you have to do is internally make a file copy and open the original and
the copy in two different modes to get the same effect and facilities.
So we''ll change our common technique a bit, in case.
| |
| Richard Maine 2006-09-16, 7:02 pm |
| Terence <tbwright@cantv.net> wrote:
> Steve says that having the same file open on two unit numbers is
> outside the standard. I believe what he says. But it didn't use to be
> and it still works (as he accepts).
No, it never has been standard - never. Working with one particular
compiler is not the same thing as being standard.
I'll not comment on the rest.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| AeroSpace Ed 2006-09-16, 7:02 pm |
| Terence wrote:
> But yes, you can change some very minor options with later new OPENs on
> an open file on the same unit (on F90/95, not on our F77), but that
> wasn't the point.
Good Grief, what is 'our F77' and why would anyone else care for advice
stemming from someone that has  Fortran with his own personal
un-branded code. Advice for compiler specific extensions and failings of a
particular compiler to correctly implement standard Fortran is only useful
if you cite the compiler and vendor and then the programmer is prepared to
accept non-portable code. A good many of us are not (at least without
knowing the pitfalls). Please cite your compiler specifics when you
deviate from the language definition.
>
> Sure, criticise errors of fact, but not personal techniques and
> preferences.
> I once suggested writing F77 code to get it working then change it to
> F90 for future maintenance. It's economical.
You have a weird definition of economical. Whoops. I think I just caught on
to your thought process here. It definitely wasn't my first reading of
your words. I thought you meant to write and debug in F77 and then
translate to F95. Which of course would be really bizarre and very
wasteful. However, if you meant to write code and compile/debug with
respect to an F77 compiler and then simply switch to an F95 compiler, I
guess it would not be a waste of double coding time. However, I really
don't see the point in maintaining F77 compliance on newer code. I don't
have a problem with that being your personal preference, however I do when
you offer it as advice to newcomers to the language. It r s of ignorance
and will send many down the wrong path.
My personal Fortran experience is about 20 years of Fortran V, 66 and 77
code. I resisted learning the newer language features for a very long
time. Once I took the plunge (when I decided to re-write a very large
library that desperately needed dynamic memory allocation), and invested
the time, I was amply rewarded. I never write strictly F77 code any
longer. I love modules and the ability to control scope.
I suggest that you really make a whole hearted stab at learning the newer
language features before you criticize them so much. I've found that my
code/debug cycle has been generally shortened because the language is
getting better. This is in direct contrast to your statements.
>
> Steve says that having the same file open on two unit numbers is
> outside the standard. I believe what he says. But it didn't use to be
> and it still works (as he accepts). To get around the standard now, all
> you have to do is internally make a file copy and open the original and
> the copy in two different modes to get the same effect and facilities.
> So we''ll change our common technique a bit, in case.
What's the purpose of 'getting around the standard'? Are trying to make
your life hard? What possible reason could you ever want the same file
connected to different units? Are trying to create a mess? I've seen it
done myself (usually in code that has had too many generations of
maintainers), but I can't think of a single reason why one would do this
now on purpose.
[color=darkred]
I probably should apologize for going on so long about your postings. My
real goal is to suggest that you qualify your advice as being 'possible
ways', or 'I've done it this way in the past, there might be better ways
now', or 'I thought, but could be wrong...'
Ed
| |
| Brooks Moses 2006-09-16, 10:01 pm |
| AeroSpace Ed wrote:
> Terence wrote:
>
> What's the purpose of 'getting around the standard'? Are trying to make
> your life hard? What possible reason could you ever want the same file
> connected to different units? Are trying to create a mess? I've seen it
> done myself (usually in code that has had too many generations of
> maintainers), but I can't think of a single reason why one would do this
> now on purpose.
Terence did mention why he was doing this, in a previous post. Note
that (as you ought to be able to guess from the fact that making a copy
works) he's _only_ doing this to read from the file, not write to it, so
there's no possibility of creating a mess. In any case, his reason is
to have some form of forward look-ahead or something like that before
processing the data.
Personally, I'd think that in most cases this could probably be done
most cleanly by reading in lines and then doing internal reads on them,
but that's not necessarily the easiest way.
- Brooks
--
The "bmoses-nospam" address is valid; no unmunging needed.
| |
| robin 2006-09-19, 10:01 pm |
| Mike wrote in message <1158118781.170523.316360@e63g2000cwd.googlegroups.com>...
>Hi
>
> I have question about the following program:
>
> program main
>
> a=1.0
> write(88)a
> open(88,file='fort.88',status='old',form='unformatted')
> read(88)a
> print *,a
> stop
> end
>
>I use CVF6.6C. The error message shows "end-of-file during read".
>If I replace the above as :
>
>read(88,end=1)a
>1 print *,a
>
>then it's ok. Why?
Is it _really_ OK?
What did you write in the first WRITE, and where did you write it?
(What was the file name?).
In the OPEN, you explicitly name the file as "fort.88".
Does a file of that name already exist?
I your code, you don't know whether the PRINT
was excecuted as a result of normal processing,
or because of the END= processing.
|
|
|
|
|