Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!dptg!mtunb!dmt
From: dmt@mtunb.ATT.COM (Dave Tutelman)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Trouble compiling flip with TurboC 1.5
Message-ID: <1571@mtunb.ATT.COM>
Date: 25 Jul 89 21:56:31 GMT
References: <26586@agate.BERKELEY.EDU> <1113@unocss.UUCP>
Reply-To: dmt@mtunb.UUCP (Dave Tutelman)
Organization: AT&T Bell Labs - Middletown, NJ
Lines: 53

In article <1113@unocss.UUCP> ho@fergvax.unl.edu writes:
>From article <26586@agate.BERKELEY.EDU>, by ked@garnet.berkeley.edu (Earl H. Kinmonth):
>
>> I almost forgot the biggest pisser of all, the inability of TC 2.0 to
>> work with lines terminated only by line-feeds, and worse yet, the
>> failure to detect this problem in many cases. (TC 1.0 actually worked
>> in this case.)
>> .....
>I'm not happy with some of the design decisions behind MSDOS either (e.g.,
>the CRLF instead of NL).  But given that I have to work with them, I don't
>see any reason why the CRLF vs. LF problem should even be a problem.
>
>Changing NL's to CRLF's is the responsibility of the transporting program,
>be that ftp, xmodem, or rz/sz, IMHO.  It should not be the responsibility
>of the application program to recognize a file which was improperly
>transported across environments.  (If you can't TYPE the file properly,
>why should Turbo C be expected to interpret it?)

Because UNIX(R) and MS-DOS can reside on the same machine.  Today's
386 boxes can run both easily.  If I have text files on such a box,
I'd REALLY like to be able to process them under each OS.  No transporting
program should be needed, because I'm really not transporting the file.
(Yes, I know I'm transporting the environment; I'm arguing practicality,
not purity.)

I recognize that we're far from there now, and may never get there.
However, I'd certainly like to see Borland be part of the solution,
not part of the problem.

>And just because Turbo C 1.0 supported that quirk does not make them 
>bound to retain the "feature" in future compilers.  

True.  I'm used to hearing that argument from my less favorite software
suppliers.  (Hmmm... I wonder whether that's random correlation or
cause and effect.)

Note that I'm a happy user of Turbo C.  I use it in preference to
the other leading C compilers (having used at least four different
brands in the past).  I'm also one of Borland's first customers,
with Turbo Pascal serial #1026.  So I'm not shooting flames at
a favorite target.  But it dismays me that they'd "break" this
very useful "quirk", when they might use it as a positive
product differentiator.

The foregoing is my own opinion.  I don't know AT&T's opinion on
this subject, so I certainly can't represent it here.

+---------------------------------------------------------------+
|    Dave Tutelman						|
|    Physical - AT&T Bell Labs  -  Middletown, NJ		|
|    Logical -  ...att!mtunb!dmt				|
|    Audible -  (201) 957 6583					|
+---------------------------------------------------------------+