Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!ncar!tank!eecae!upba!dsndata!unocss!ho@fergvax.unl.edu From: ho@fergvax.unl.edu Newsgroups: comp.sys.ibm.pc Subject: Re: Trouble compiling flip with TurboC 1.5 Message-ID: <1113@unocss.UUCP> Date: 24 Jul 89 00:42:13 GMT References: <26586@agate.BERKELEY.EDU> Sender: news@unocss.UUCP Reply-To: ho@fergvax.unl.edu Lines: 43 From article <26586@agate.BERKELEY.EDU>, by ked@garnet.berkeley.edu (Earl H. Kinmonth): >>What would you consider a (not almost, but actually) good PC C compiler? > > One that allowed larger programs to be debugged. I was looking for the name of a compiler which was better than Turbo C. > utime() and a number of other **IX functions available in MSC were not > and still are not part of the Turbo C library. You're right -- the lack of utime() has actually bothered me... I had to find some non-standard function to cover it. It would be fairly simple to write a utime() function, but why it wasn't included, I don't know. > 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.) > > Before you respond that CR/LF is the MSDOS convention and TC is a MSDOS > compiler, let me give you my rebuttal. First, LF lines did work in TC > 1.0. Second, it takes MORE code to require the CR/LF than not to. > Third, since a major selling point of C is portability, TC should not > make moving code anymore difficult than is required by the underlying > platform. 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?) And just because Turbo C 1.0 supported that quirk does not make them bound to retain the "feature" in future compilers. I'm not frustrated at all by that problem... the lack of utime(), lint, and a curses package seem much more pressing than a ^M^J vs. ^J fight. --- ... Michael Ho, University of Nebraska