See http://gcc.gnu.org/ml/fortran/2006-09/msg00415.html
Brooks Moses wrote:
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 [10.6.3] 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.)
--
Summary: Formated stream output: Translate "\n" / achar(10) into
"\r\n" on some platforms
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias dot burnus at physik dot fu-berlin dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29277
