This is the mail archive of the
mailing list for the GNU Fortran project.
Re: Stream-reading question
- From: Jerry DeLisle <jvdelisle at verizon dot net>
- To: Brooks Moses <bmoses at stanford dot edu>
- Cc: fortran at gcc dot gnu dot org, Tobias Burnus <tobias dot burnus at physik dot fu-berlin dot de>
- Date: Sat, 07 Oct 2006 17:20:44 -0700
- Subject: Re: Stream-reading question
- References: <email@example.com> <4528293A.firstname.lastname@example.org>
Brooks Moses wrote:
Tobias Burnus wrote:
I agree with this and I will look into whats going on with formatted stream. I
would suggest simplifying the test case for the NEWLINE() intrinsic to avoid
this problem and I will use the example you have given here as a test case for
the stream I/O fix.
Assume I have a file (e.g. created via 'line1'//new_line('a')//'line2'):
what shall the following program print?
character(len=50) :: r1,r2
print *, ':',trim(r1),':'
print *, ':',trim(r2),':'
end program stream
NAG f95 prints:
I think NAG f95 is right as I find in Fortran 2003, section 10.6.3:
"If the file is connected for stream access, the output may be split
across more than one record if it
contains newline characters. A newline character is a nonblank
character returned by the intrinsic
function NEW LINE. Beginning with the first character of the output
field, each character that is not
a newline is written to the current record in successive positions;
each newline character causes file
positioning at that point as if by slash editing (the current record is
terminated at that point, a new
empty record is created following the current record, this new record
becomes the last and current record
of the file, and the file is positioned at the beginning of this new
But I'm not 100% sure, whether I read this correctly (or whether this is
the right place in the standard).
I agree with your assessment (with a minor irrelevant exception).
There are two issues at hand, though, and your paragraph addresses only
one of them, and I'm not sure it addresses the relevant one unless
you're testing on a machine with DOS line endings.
Presuming that the file in question is equivalent to any other file that
looks like this on the system, and in particular that the line ending
between "line1" and "line2" is a standard line ending for the system,
then the issue is how much of the file the read statement should read.
The paragraph you quote only addresses writing, not reading, so it
doesn't apply. What does apply is the description of the "A" edit
descriptor in formats, which says that when it gets to the end of a
record it stops, and there is no provision for stream access doing
anything different. Thus, if there is indeed a proper line ending for
the system between "test1" and "test2", then the NAG results are most
definitely the correct ones. There is no way that the first read
statement should read past a system line ending.
The second question, then, is whether or not the particular write
statement in your example should produce a file with a system line
ending between those two lines. In my opinion, the paragraph you quote
states that for FORMATTED STREAM output, the compiler "may" translate
ACHAR(10) characters in the printed string into system line endings on
systems where the standard line ending is something different (e.g.,
Windows). Moreover, I think it's fairly clear that this is what ought
to be done, and what the authors of the standard expected would be done.
Thus, I think it is also true that this should produce the NAG results
regardless of the type of system it's being used on.
(The minor exception is that the "may" is a loophole such that it's not
absolutely _required_ by the standard. I am of the very strong opinion
that it is not a good idea to use this loophole, though.)
I will make one note about the descriptive comment on your test program,
though. IMO, this is not a test of the NEW_LINE intrinsic (which can be
completely tested by comparing its output to ACHAR(10) and confirming
that it has a length of 1.), so much as a test of the interaction
between that intrinsic and the stream file access functionality. The
failure you see is a failure of the stream functionality, not of the
I am already working on the writing of \n for formatted stream I/O, so it makes
sense I make sure we get the reading correct as well.
Thanks for the reports and interpretations,