F2003 access='stream' question

3 views
Skip to first unread message

David Frank

unread,
Apr 3, 2004, 3:08:42 AM4/3/04
to

program f2003_question
integer :: item1
character(10) :: item2
real :: item3

open (1,file='test.txt') ! create a test file
write (1,*) '123 DOG 1e-12' ! record 1
write (1,*) '12345.6789 44 CAT' ! record 2
close (1)

open (1,file='test.txt',form='formatted',access='stream')
read (1,*) item1, item2
read (1,*) item3
write (*,*) item3 ! what will be the output in F2003?
end program


Robert Corbett

unread,
Apr 4, 2004, 4:00:31 AM4/4/04
to
In article <eiubc.380626$B81.5...@twister.tampabay.rr.com>,

I imagine that for most implementations, it will write a value
that approximates 12345.6789. The draft proposed revised
standard gives you no guarantees. The first OPEN statement
opens the file for sequential access, while the second OPEN
statement opens it for stream access. The standard does not
require the two to be compatible. Also, since you did not
specify a POSITION= specifier on either OPEN statement, you
have no guarantee where the file will be positioned after it
is opened.

Sincerely,
Bob Corbett

David Frank

unread,
Apr 4, 2004, 5:47:44 AM4/4/04
to

"Robert Corbett" <cor...@lupa.Sun.COM> wrote in message
news:c4ofav$g3i$1...@news1nwk.SFbay.Sun.COM...

My question is whether the stream option will inhibit advancing the record
count
when the test file's first list items are read.

If the 2nd read doesnt resume reading where the 1st read left off, then
stream option
does NOTHING in this case that current Fortran would not do.

I'm surprised you say we have no guarantee that opening a file with no
position
specifier is not ALWAYS defaulted to file start.


Dick Hendrickson

unread,
Apr 4, 2004, 12:55:34 PM4/4/04
to

Well, you shouldn't be ;-) . Many (well OK, one) early F77
implementation OPENed files at the terminal point, the
reason being it was relatively easy to REWIND the file to
the starting position and relatively hard to position it
at the end for appending. That's probably why the
POSITION= stuff on OPEN was added in F90. F95, the one
I have handy, says that "[POSITION=] ASIS leaves the
position unspecified if the file exists but is not
connected" and that if there is no POSITION=
specifier, the default is ASIS. I believe that is
partially to allow the program to get at files that
have been manipulated somehow by the user/OS before the
program starts; that was a relatively common extension.
Remember that in this era of disk files, back in the good
old days "file" and "magnetic tape" were synonyms and
this causes some funny holdovers in the language.

I'm not sure I really understand your first question,
but I think the answer might be that stream I/O does
allow a record structure to be superimposed on the
data stream but doesn't require one.

Dick Hendrickson

James Van Buskirk

unread,
Apr 4, 2004, 2:03:20 PM4/4/04
to
"David Frank" <dave_...@hotmail.com> wrote in message
news:4RQbc.382673$B81.5...@twister.tampabay.rr.com...

> I'm surprised you say we have no guarantee that opening a file with no
> position
> specifier is not ALWAYS defaulted to file start.

The problem is much worse in C++ than Fortran. I had a program
that would read a file to EOF and then had to read it again.
Worked fine in MSVC++ on NT, but the same program failed with
g++ on LINUX. After going through a bunch of documentation
(you have do read piles of docs to do any I/O in C++; it's just
too complicated to keep that much stuff in your head just so
you can do programming) I found there was a way to tell C++ to
reposition the file pointer to the beginning (there is the
equivalent of POSITION='APPEND' but not POSITION='REWIND' in
the C++ syntax for opening a file) and the code worked, but it
unfortunately also had to work in SUNOS. I gave up on this
futile effort, but one of my friends who actually programs C++
for a living told me when I was raving about this incident that
the C++ stream state data structures (this is one thing that
C and C++ do better than Fortran: I think it's quite lame to
manage files via effectively a global array rather than having
data structures you can allocate as needed and hide from other
subprograms) have a bit that indicate whether the stream state
is good or bad and that when you read a file to EOF that bit
gets set (or cleared or whatever) but then on some platforms,
for your convenience, that bit doesn't get changed when the
file is closed or when it is reopened using the same variable
to hold the stream state. How intuitive! Anyhow, it's possible
if the implementor thinks about things perversely enough that
even in Fortran a file could get reopened or even opened in
an unexpected state; just be happy that a way is provided in
the OPEN statement to reset things to normal without having
to have about 99% of your brain cells hardwired to Fortran to
figure out how to do it.

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end


Roy Lewallen

unread,
Apr 8, 2004, 7:15:25 AM4/8/04
to
Perhaps one of you file experts can answer a question. Is there any way
in Fortran (specifically, CVF) to find the position of the file pointer,
i.e. where the next read or write will occur? And does anyone know of a
Windows API call that can do this for a file opened with CreateFile?

Thanks,
Roy Lewallen

David Frank

unread,
Apr 8, 2004, 7:53:08 AM4/8/04
to

"Roy Lewallen" <w7...@eznec.com> wrote in message
news:107ad2j...@corp.supernews.com...

See FTELL documentation for your 1st question.


Jugoslav Dujic

unread,
Apr 8, 2004, 8:59:43 AM4/8/04
to
Roy Lewallen wrote:
| Perhaps one of you file experts can answer a question. Is there any way
| in Fortran (specifically, CVF) to find the position of the file pointer,
| i.e. where the next read or write will occur?

FTELL (nonstandard) (see also FSEEK)
INQUIRE(NEXTREC=) (for direct access only)

| And does anyone know of a
| Windows API call that can do this for a file opened with CreateFile?

SetFilePointer (right, SET!) with offsets of zero and method FILE_CURRENT.

--
Jugoslav
___________
www.geocities.com/jdujic

Please reply to the newsgroup.
You can find my real e-mail on my home page above.

Richard Maine

unread,
Apr 8, 2004, 12:26:44 PM4/8/04
to
Roy Lewallen <w7...@eznec.com> writes:

The subject line mentions F2003 and access='stream'. I can answer
for that case. That would be the pos= specifier in inquire.
(It is a bit unfortunate that pos= and position= are different
things, but position= was already "taken" and it was hard to
come up with a better term.)

But you mention CVF in the text. If we are talking about
compilers that actually exist now instead of about the future
standard...

For f95 and before, there is no standard way. The closest to such
a thing would be nextrec=, but that is only for direct access and
probably doesn't fit your needs (though I suppose it might be
possible).

Afraid I can't give you any CVF-specific answers except by searching
the documentation (and I see no particular reason why I'd be any
better at such a search than anyone else), and I certainly know
nothing worth mentioning about any Windows APIs that might be
relevant. Maybe someone else for those answers.

--
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

Roy Lewallen

unread,
Apr 8, 2004, 3:40:31 PM4/8/04
to
Thank you all for your help. FTELL wasn't in the index of the printed
manual, but I found it in the on-line help. I use SetFilePointer (for
setting the position when doing direct-type access) but hadn't thought
of the scheme Jugoslav mentions to retrieve the position. Those were
just what I was looking for -- thanks again.

Roy Lewallen

Reply all
Reply to author
Forward
0 new messages