Clive Page said:
> I had assumed that with stream output, the information from the
> data-transfer list of the WRITE statement would just be appended to the
> output file.
That is indeed the normal case.
> But a careful reading of the Standard makes it look much
> more complicated.
Only when you are doing more complicated things.
> For unformatted stream I/O, there can be a POS= specifier in the WRITE,
> and POS is only allowed for READ/WRITE on files opened for stream access
> - so far so good. Then I read in 9.5.1.10 that for formatted access the
> only allowed values of the POS specifier are 1 or the value returned by
> an INQUIRE statement.
Right. This happens to be identical to the C language requirements
for these kinds of files. See 7.19.9.2 of C99.
Note:
F2003 formatted streams == C text streams
F2003 unformatted streams == C binary streams
> This seems to restrict output to the current end
> of the file, or to its start.
No more than it does for C (which calls INQUIRE ftell and POS= fseek).
Consider (pseudocode)
OPEN stream
WRITE stream, "A"
INQUIRE position = "I"
WRITE stream, "B"
WRITE stream, "C"
READ (stream,POS="I") X
then X is being read from the position inquired earlier, i.e. it will
pick up "B".
The standard even uses the phrase "previously returned", which I would
hope is a clue here.
> By positioning at the start, one would
> seem to be overwriting its current contents there - but it is not clear
> whether the previous contents further down the file are preserved or
> not.
This is covered in "9.2.3.3 File position after data transfer".
For formatted streams, the file is truncated at that point, just
like ordinary (Fortran) formatted sequential files. C allows the
system either to truncate or not to truncate, at its whim. (I think
the Fortran situation is better here.)
For unformatted streams, maybe the wording is not quite as clear as
it could be, but 9.2.3.3 2nd para 2nd sentence indicates that the
terminal point of the file is changed
"if the file position exceeds the previous terminal point"
Yes, it doesn't say "if and only if", and that would be clearer
wording. Given that these are modelled after C binary streams, which
are NOT truncated, I would say that there is little doubt as to the
intention.
> If one can partially overwrite the start of a file, there seems no
> reason to prevent a partial overwrite at some other intermediate point.
Sure.
> Or did I miss something?
No.
> As it is, with a formatted READ or WRITE, to move successively along the
> stream it looks as if you have to have an INQUIRE by position before
> every READ or WRITE. Can this really be true?
No, and I don't know where you got that idea from.
> It also seems permissible to miss out the POS= in a WRITE or READ, in
> which case 9.2.3.2 says that the file position is unchanged.
Can I point out that 9.2.3.2 is "File position prior to data transfer".
It does ***NOT*** cover
(a) File position during data transfer
and
(b) File position after data transfer
> This seems
> to mean that successive WRITEs will just repeatedly overwrite at the
> current point, and repeated READs just read the same thing repeatedly.
No, it says that no positioning occurs prior to data transfer.
> I can't see the value in that.
Just as well the standard doesn't say it then.
Actually, I really do sympathise here, because this part of the
standard has always been hard to follow. Anyway, I'll point out
9.5.3.4.1 Unformatted data transfer
whose 4th paragraph reads
"After each value is transferred, the current file position is moved
to a point immediately after the last file storage unit of the
value."
I don't have the time right now to find the equivalent for formatted
streams. Maybe the standard is defective, maybe not. Anyway, the
place to be looking is the data transfer operations, not what happens
after they are finished.
> For unformatted stream I/O, there seems no similar restriction on the
> value of POS=, but 9.2.3.2 says that if there is no error then the file
> position is not changed. I do not understand the reason for this.
You seem to be talking about 9.2.3.3 here instead of 9.2.3.2.
Anyway, it is true. No additional positioning takes place.
So the only positioning is that which takes place during the data transfer.
> Nearly all of this seems counter-intuitive to me: I guess the inventors
> of the stream I/O facility must have had some model of stream files in
> mind which I have failed to understand. If anyone can enlighten me, I
> would be grateful.
Much of what you have said seems counter-intuitive to me too!
Anyway, the only potential problem I see is the possible lack of
sufficient specification of file positioning during formatted data
transfer. (Actually, this might affect sequential files too, not
just streams.) That certainly merits more investigation.
Cheers,
--
...........................Malcolm Cohen, Nihon NAG, Tokyo, Japan.
([log in to unmask])
|