leder@ihlpm.ATT.COM (Leder) (06/05/87)
Below are some of the responses with answers to some questions that I received about TURBO C. After talking to the folks at BORLAND, they stated that currently they have no interest in holding dicussions both here and on COMPUSERVE. Also, I would like to appologize to anyone that was offended by my previous article and might have thought that I had something to gain in promoting TURBO C. I was only stating my own personal opinion based on the products that I have used in the past and I do not personally have the resources to purchase nor would my company pay me to evaluate every compiler on the market. After saying all of that, I am still very happy with TURBO C. My only problem before was adjusting for a larger stack. The solution is to create an external variable, _stklen, and initialize it to the value wanted. The initial value is 1000 bytes. The MSC default is 2048. The remainder of this article is a composite of letters and articles that I have received in the past few days. The inserted comments are the responses that I got from BORLAND and may be subject to my typos: > From: <nosc!sdcsvax!nosc!humu!uhccux!aloha1!aloha3!ee669947> > Subject: TURBO C Bugs > Organization: University of Hawaii, Honolulu > Cc: > Status: R > > In article <1148@ihlpm.ATT.COM> you write: > >If others want to send info (bugs, etc.) I will summarize on the net. > > I haven't received my copy of TURBO C yet, but I have heard of the following > bugs: > 1. printf("%f\n", 12.0 / 4.0); > will result in 0.333333 They are aware of this bug and there is a fix on compuserve, but I don't have it yet. > 2. strstr("ABC", "C") > will return NULL This fails on the last character. I would think that it would be a good idea to provide a sacrificial character. > 3. if the environment variable TARGASET=abcdef > (i.e. C>set TARGASET=abcdef), getenv("TARGASET") will return abcdef > but getenv("TARGA") will return SET=abcdef > The getenv will match as though a strncmp with the length of the target string is used. > From: iverson@cory.Berkeley.EDU > > In article <1148@ihlpm.ATT.COM> you write: > >TURBO C IS ALIVE AND WELL! > > Well, that's nice - at least Borland ships what they announce. Now > on to the meat of the problem: can CodeView use the resultant .exe file? > What does dhrystone really work out to? (never trust the adds, they're > always wrong) > > - Tim Iverson > iverson@cory.Berkeley.EDU > ucbvax!cory!iverson > Subject: Borland's Turbo "C" is good Date: Tue, 02 Jun 87 17:39:21 PDT From: jimc@MATH.UCLA.EDU I made a quick test of Borland's Turbo "C" on our machines, compiling the Drystone benchmark, a program of 467 lines / 14.5 Kbytes which tests non- floating-point operations. I also compared the performance of Microsoft "C". Timing was as follows (VAX data for reference): Compiler Code size Compile Link Run -R Run +R PC-AT, hard disc, msc temp files on RAMdisc tcc 23750 6 5 39 (1282) 41 (1219) msc 23084 28 14 48 (1041) 47 (1063) PC-XT, hard disc, no RAMdisc tc (Same) 17 10 124 ( 403) 123 ( 406) msc 82 24 149 ( 335) 137 ( 364) PC-XT, dual 360Kb floppy tcc 39 41 (Same) (Same) msc 139 102 VAX 11/780, sysV.2 cc ~33 (1565) ~32 (1515) Times in seconds, code size in bytes. The run numbers in parens are the drystone rating in thousands of passes per second. "-R" is without register variables and "+R" is with; drystone is not register-intensive. "tcc" is the analog of UNIX "cc", while "tc" is the "integrated development environment" with menus, built-in editor, etc. Their compilation speed was the same. RAMdisc is not used; the compiler puts temporary data in a giant core allocation, so the effect is the same as a RAMdisc. The compiler-linker produces standard .OBJ and .EXE files. As with UNIX cc, linking is automatic unless suppressed with -c. The compiler can fork masm (Microsoft assembler) for .ASM files. The compiler compiled the file with no problems. The "integrated development environment" was easy to use (I am familiar with the Turbo editor, which was ported), and I very much appreciate the feature to coordinate error messages and the source code location of the error. One problem: since the editor window shares space with the error messages, the main menu line and the help line, you get only about 12 lines on the screen. There may be a way to devote the whole screen to editing -- I didn't have time in this quick evaluation to thoroughly learn the editor setup controls -- but if not I would want to do major coding and revisions with another editor, e.g. Micro-Emacs in 43-line mode. The editor was fine for fixing small errors, though. And unlike Turbo Pascal, you compile the whole program and get to see all the error messages at once. The libraries and include files seemed complete -- even a getFAT function, of all things. 8087 support is included (but I didn't test it). The documentation was nicely laid out (and printed with the traditional UNIX fonts!) What I scanned seemed complete. The manuals are easier to use than the manual for Turbo Pascal. In summary, this compiler would be an excellent buy at Microsoft prices, and is a steal at $99 (list; substantial discounts available). I'm going to buy one for myself. James F. Carter (213) 825-8861