This is the mail archive of the mailing list for the GNU Fortran project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Stream-reading question

Brooks Moses wrote:
Tobias Burnus wrote:
Assume I have a file (e.g. created via 'line1'//new_line('a')//'line2'):
what shall the following program print?

program stream
implicit none
character(len=50) :: r1,r2
read(10,'(a)') r1
read(10,'(a)') r2
print *, ':',trim(r1),':'
print *, ':',trim(r2),':'
end program stream

NAG f95 prints: --------------- :line1: :line2: ---------------

gfortran 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 intrinsic itself.

- Brooks

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.

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,



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]