Re: Stream-reading question

[Brooks Moses <bmoses at stanford dot edu>]

Tobias Burnus wrote:
> Assume I have a file (e.g. created via 'line1'//new_line('a')//'line2'):
> ---------------
> line1
> line2
> ---------------
> what shall the following program print?
>
> program stream
>     implicit none
>     character(len=50) :: r1,r2
>     open(10,file='test.dat',form='formatted',access='stream',status='old')
>     read(10,'(a)') r1
>     read(10,'(a)') r2
>     print *, ':',trim(r1),':'
>     print *, ':',trim(r2),':'
> end program stream
>
>
> NAG f95 prints:
> ---------------
>  :line1:
>  :line2:
> ---------------
>
> gfortran prints:
> ---------------
>  :line1
> line2
> :
>  ::
> ---------------
>
> 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
> record)."
>
> 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