Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!uxc.cso.uiuc.edu!uxc.cso.uiuc.edu!ux1.cso.uiuc.edu!uxe.cso.uiuc.edu!mcdonald
From: mcdonald@uxe.cso.uiuc.edu
Newsgroups: comp.sys.ibm.pc
Subject: Re: Trouble compiling flip with TurboC
Message-ID: <45900257@uxe.cso.uiuc.edu>
Date: 30 Jul 89 17:46:00 GMT
References: <14517@dartvax.Dartmouth.EDU>
Lines: 22
Nf-ID: #R:dartvax.Dartmouth.EDU:14517:uxe.cso.uiuc.edu:45900257:000:967
Nf-From: uxe.cso.uiuc.edu!mcdonald    Jul 30 12:46:00 1989


>As someone else mentioned n passing, MS-DOS's convention eats up 2K on a
>2000-line file, to no advantage.  Programs that process input streams
>have to do more work to handle End-Of-Lines; not much, but a bit more.

>Forgetting compatibility, the Unix convention just makes more sense.

No, it doesn't, at least for ASCII. In ascii, carriage return and
line feed are separate characters. Ascii terminals require both
to get to the left hand side of a new line. Thus, with the MS-DOS
convention, a text file is a plain file - no translation is necessary
for it to be sent to a terminal. For Unix, text files must be translated
so a lf sends out both a line feed and a carriagereturn - and this
means it is impossible to send out a linefeed alone. 

If ascii had a newline character, then everybody would be the same,
but it doesn't 
have that - it has a separate line feed and carriage return.

C's use of a single newline indicator is an oddity too.

Doug McDonald