From: <[EMAIL PROTECTED]> > > 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 conformance). I just wonder if more recent C/C++ compilers for MacOS still compile a CR for the '\n' _source_ string or character constants.
