(j3.2006) Partial write in record with nonadvancing I/O
Wed Feb 29 22:50:48 EST 2012
On Wed, 2012-02-29 at 16:36 -0800, Malcolm Cohen wrote:
> I wrote:
> > Asserting that it is ambiguous does not make it so - show the ambiguity.
> Van replied:
> >An indication of where the standard (plus interps if necessary)
> >specifies which of the three observed outputs is correct would be
> Ah, so we have moved on from "ambiguous" to a claim of "not specified". That is
> a horse of an entirely different colour.
> Anyway, the standard says where the left tab limit is, where the file position
> is, and what the effect of the various edit descriptors is. I see no particular
> I should perhaps remind people that "interpretation request" is not there for
> the committee to do your homework. It is there to report *DEFECTS* in the
> standard - indeed the ISO terminology is "Defect Report".
> Going back to the left tab limit, the file position, and the effect of the edit
> descriptors: I am frankly astonished that there is any difficulty in processing
> these concepts and in tracing the effect on the program. It is *INCREDIBLY
> TEDIOUS*. But I see no actual difficulty.
Here's some of Tobias's original example, for reference:
1 WRITE (10, '(A)') 'ABCDEFGHIJKL'
2 REWIND 10
3 READ (10, '(TR4)', ADVANCE='NO')
4 WRITE (10, '(TL2, A)', ADVANCE='NO') 'MNOP'
5 REWIND 10
184.108.40.206p2 says a nonadvancing read may position a record file at a
character position within the current record. So statement 3 positions
the file between the fourth and fifth characters of the first record.
Assuming the "current record" is the same for reading and writing a
file, statement 4 then positions the file between the eighth and ninth
characters of the same first record.
Assuming the "current record" is different for reading and writing a
file, statement 4 positions the file between the fourth and fifth
characters of the first record.
It is not obvious which assumption to make. Sequential I/O in Fortran
was originally based upon tape, where reading a record physically
positioned the medium between records. Nonadvancing I/O could, in the
context of tape, muck with the buffer, but not the physical position of
220.127.116.11p2 further says that if a nonadvancing write leaves a file
positioned within the current record, executing a REWIND statement has
the retroactive effect of an advancing write.
Subsequently writing a record on tape necessarily writes it after the
first record, absent a BACKSPACE statement, which doesn't appear in
Tobias's example. Therefore, if the physical medium is tape, the former
assumption is impossible unless the processor inserts a hidden BACKSPACE
It would be helpful if 18.104.22.168p2 were to specify whether a nonadvancing
read followed by a write (nonadvancing or not) has the retroactive
effect of advancing. By omission, it implies it does not. If it should
not, a note would be helpful, since to accomplish the feat of not
implying completion of an advancing read if a nonadvancing read is
followed by a write, an intervening hidden BACKSPACE is required if the
physical medium is tape. If it should, normative text should be
Acting on the former assumption, and observing that 22.214.171.124p2 says that
the effect of a REWIND after a nonadvancing write is as if the write
were advancing, seems to suggest the file should contain "ABCDMNOP".
Three of my four processors agree with this analysis.
I have no confidence this analysis is correct, because it requires an
inference based upon the absence of something that would logically
appear in 126.96.36.199p2 if it were to appear anywhere, but that could, in
principle, be stated somewhere else (but which I did not find after a
Acting on the latter assumption, the contents of the file should be
"ABCDEFGHIJKL" followed by "MNOP". One of my processors agrees with
I have no confidence this analysis is correct, because it rests upon
assumptions concerning the mechanical properties of a device and medium
that inspired the original feature, but that have largely fallen into
disuse, notwithstanding that other terms of reference (REWIND,
BACKSPACE) apply to that device. It appears, by apparent omission at
least, to have weaker support than the alternative.
I can't see a way to make a case that the file ought to contain
As Malcolm remarks, "Improving exposition is a topic for the next
revision, not for a defect report." No matter which of the foregoing
analyses is correct, improved exposition would be helpful.
> People who have difficulty and want some step explaining should at least attempt
> to reason out from those three concepts I just named and apply them to their
> example programs. I would hazard a guess that those having difficulty would
> find their problems resolved.
Additional assumptions are required: Either the external medium is not
tape, or if it is the processor is required to insert a hidden BACKSPACE
between the necessarily advancing read that filled the buffer upon which
statement 3 operates, and statement 4. The problem is not resolved
unless one assumes that "file" is an abstraction that doesn't work as
some external media would require it to work.
> Rafik Zurob wrote:
> >I've been following this discussion closely and would like to add my voice
> >to that of the ones saying that this section of the standard is not very
> >clear. (Maybe it's not ambiguous, but it's not very clear.)
> Improving exposition is a topic for the next revision, not for a defect report.
> I certainly agree that our exposition can be improved here, but... wording
> changes are not a risk-free endeavour. We can do editorial changes with high
> reliability (though not quite 100%) but going beyond editorial certainly risks
> breaking things.
> >I'm also interested in the expected output with stream access.
> Since we are talking about formatted streams here, it is the same as sequential:
> "For a formatted stream output statement, if no error condition occurred, the
> terminal point of the file is set to the next position after the
> highest-numbered position to which data was transferred by the statement."
> Contrary to claims, it is not actually difficult to find this info... but it
> certainly is tedious! And it sounds like IBM has a bug to fix...
> BTW, those wanting this to be simple and easy to understand should remember that
> we are talking about i/o here, and with a very general model that applies to all
> kinds of i/o systems (not just the trivial Unix byte stream model). Simplicity
> is not on the menu.
That's certainly true, but not a valid excuse for avoiding improvement
More information about the J3