The standard talks about records but is silent on how the underlying implementation separates records. OpenVMS, for example, supports many on-disk formats, the oldest of which use metadata not visible to the user to indicate the length of each record. You cannot assume any particular character sequence visible to the user.
The standard is very clear on the return value of the NEW_LINE
intrinsic - it is ACHAR(10)
or CHAR(10,KIND(A))
if that is representable. Only for STREAM
output does this have a meaning. If you are on a platform such as Windows where LF
is not the record separator for stream output, the implementation must convert that single LF
to whatever the appropriate sequence is.
For example, I ran the following program using ifx on Windows:
open (unit=1,file='test.txt',form='formatted',access='stream')
write (1,'(*(A))') 'ABC',NEW_LINE('a'),'DEF'
end
If I look at the file using a binary editor, I see:
41 42 43 0D 0A 44 45 46 0D 0A
in other words, that single LF
got turned into CR LF
by the ifx runtime library.
What this means is that you can write stream files in a platform-independent fashion and depend on the implementation to do whatever is required to create the indicated records.