I had lengthy discussions with CVS on similar topics, and resorted to hacking my own CVS to work properly, that is, if a text file has \r\n, keep \r\n, do not convert to \r\r\n. If a text file has \r or \n in some sequence [\r\n]* this is an end of line, if \n's exist multiply, there are blank lines. (unless you're on a MAC that uses \r for newlines?!)
If a file is checked in and developed by a developer which is using both windows and linux, her tools will of course support both cases for files in both environments which must be developed in either.
There is little requirement for conversion, and eventually, conversion is self recursive.
On a note from some windows programmer that appreciated the conversions when checking out linux-like sources to have 'notepad' work as a browser; While some days I can agree, in the end, one must make sacrifices and call a goat a goat, and know that you need to use a smarter tool than notepad to deal with text files.
Linux tools rarely care about the presence or absence of \r's... they're redundant other than the classic teletype need to send a carriage return before the line feed. If you sent the line feed first, then the carriage return wouldn't have enough time to happen before processing a the next character, and the letter would strike before the head reached the return point. Sometimes I wonder if people actually learn from history at all... Modern equipment rarely even requires a carriage return, being of a digital nature, you cannot gain cheap effect like <b>BOLD</b> by sending 'BOLD\rBOLD\rBOLD really ...' to a printer device... thermal and laser printers will not gain any effect because there is no ribbon.
I actually cannot think of a sane reason that I would ever want a line feed without returning to the start <cr>
In the end, I'm sure everyone will disagree, the developers will say it works good enough, and it'll remain broke, lest the break what already works fixing something that isn't broken.
Unless you expect users to be lame and use notepad to edit text files, never open a file with fopen("file", "t" ); but always specify the flag fopen(file, "b"); even under linux environments this does not hurt. If you mean text, say text, always read binary and disregard \r as whitespace. disregard also \n as whitespace.
Nothing seems to have a problem not converting tab charaters into spaces.