The world is stranger than you understand...
Exactly. If you read a text file as binary, then the the line
terminator will not be translated. It could appear as anything;
a single arbitrary character, a sequence of characters, or nothing
at all.
Conversely, treating a text stream as binary can lead to spurious
'\n's being injected into the stream or to characters being
removed. On some platforms this breaks many stdin -> stdout
binary filter program (stdin and stdout are supposed to be text
streams).
Good timing...I recently started reading K&R2 for the first time and
just now reached Section 1.5. I'm glad this was pointed out to me
here before I read that bit, or I might have missed its importance.
If I had ever thought about it I'd have realized that there are all
kinds of systems out there that use all kinds of coding, including
EBCDIC and fixed line lengths. But only being experienced with *nix
and MS-DOS (and maybe due to stuff I read in my old Borland C
manual), I'd assumed \n and \r\n covered all possibilities.
So, my new understanding: if you open a stream with "r" or "w", the
program will read and/or write lines terminated with '\n', but the
actual file or whatever on the system may have a completely
different representation, and the library translates between the
two. If you open a file with "rb" or "wb", you get straight binary,
no translation. Don't mix them. And stdin, stdout, and stderr are
text, not binary. All correct?
Thanks to all for straightening me out!