Stream-reading question

[Jerry DeLisle]

Brooks Moses wrote:
> 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
> 
> 
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,

Regards,

Jerry