From: Philippe Verdy (email@example.com)
Date: Wed Oct 22 2003 - 01:59:39 CST
> I wrote:
> > So this legacy encoding of end-of-lines is now quite obsolete
> > even on MacOS.
> I don't think it can be called "obsolete" as long as files generated using
> that line end convention exist. Or, at least, applications that have an
> operation for "read a line" will have to cope with it. (In other words,
> all of the CR LF CRLF LFCR should mark an "end of line".)
I was not speaking about the actual encoding of files into bytes, but
only about the interpretation of '\n' or '\r' in C/C++, which was the real
subject of the message.
You are refering to the run-time behavior of I/O readers/writers for
files or network messages, and of course this is not obsolete, as the
plain/text MIME format, as well as RFC822 message format (also used
in the HTTP protocol) still use a CR+LF sequence for end-of-line
marks in headers (this is even mandatory for RFC-822 and HTTP
I just wonder if more recent C/C++ compilers for MacOS still compile
a CR for the '\n' _source_ string or character constants.
This archive was generated by hypermail 2.1.5 : Thu Jan 18 2007 - 15:54:24 CST