Re: problem writing cstring to file

It turns out that Unix made an error in adopting LF, since LF is defined
as moving the
output device vertically without actually returning the carriage to the
left side. That's
why CR and LF have different meanings; CR moves horizontally to the left,
with no vertical
motion, and LF moves vertically with no horizontal motion. Every
operating system UP
UNTIL UNIX understood this. But Unix "optimized" the idea by using just
LF to mean CRLF.
They were quite proud of this. So the C libraries had to support it, and
on all systems
since, \n always has to be translated to \r\n for output on most devices.

It didn't help that many programs assumed that CR mean end-of-line and LF
was ignored,
while other programs assumed that LF meant end-of-line and CR was ignored
(the only valid
convention that always worked correctly was to ignore CR and depend on LF.
I once used a
program where CRLF meant end of line and LFCR meant "continued on next
line" and it only
worked in the one editor that existed that allowed a LFCR pair to be
inserted; every other
editor was unable to edit the source files. The language was PPL, the
Polymorphic
Programming Language, and it only supported the editor its designer liked
to use)