[Patch, fortran] PR28585: Add Fortran 2003 NEW_LINE intrinsic function

[Brooks Moses]

Tobias Burnus wrote:
> Brooks Moses wrote:
>>Unfortunately, this _does_ mean that in a standard-compliant
>>implementation, the following commands will produce different files on a
>>system that uses \n\r as a newline -- but that's an issue with the
>>standard, not with the implementation:
>>
>>    WRITE(*,'A') this // NEW_LINE(this) // that
>>    WRITE(*,'A') this, that
> 
> I assume you mean
>    write(*,'(A)')     this // NEW_LINE(this) // that
>    write(*,'(A,/,A)') this, that

Sort of -- I did forget the parentheses, but I did mean to use '(A)' for 
both.  The behavior on the second line would be identical in either 
case, however.  :)

On the other hand, I do wish to revise my earlier position.  If these 
are written to a file that is opened for formatted stream access, rather 
than writing to *, the two write statements should produce identical 
results.

> The purpose of new_line() seems to be (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)."
> 
> The "as if by slash editing" does not seem to be fulfilable, however.

No, it's perfectly fulfillable; when a file is connected for stream 
access, the runtime library could very easily do a s/\n/\r\n/ on the 
output stream before writing it to the file.  In fact, if we consider 
\r\n to be a record marker (on a given system), and we do wish to 
implement the behavior described in this paragraph (note that "may" 
means that it's not a requirement, and implies "may not" as a valid 
choice!) then it would be required to do so.

Actually, now that I read section 9.2.2.3 (and particularly note 9.9) on 
the Fortran 2003 Standard, I'm pretty sure it was the intent of the 
standard committee that this sort of substitution be done.  Note 9.9 states:
> There may be some character positions in the file that do not correspond
> to characters written; this is because on some processors a record
> marker may be written to the file as a carriage-return/linefeed
> or other sequence. The means of determining the position in a file
> connected for stream access is via the POS= specifier in an INQUIRE
> statement (9.9.1.21).

Note, in particular, that this whole matter only applies to _formatted_ 
stream files -- that is, files which are expected to contain 
human-readable text that could be edited in a text editor.  For 
unformatted stream files -- which are the only ones that should be 
containing "binary" data that would be corrupted by the substitution -- 
this doesn't apply, and no substitution would be made.

Thus, I think it's pretty clear that NEW_LINE should return ACHAR(10), 
and that for formatted stream-access files, the runtime library should 
convert that character to the appropriate system-specific line-ending 
string when writing to files.  (This substitution would not be a 
regression against g77, because files opened for stream access do not 
exist in g77 code, and the substitution would not be made for non-stream 
files.)

- Brooks