Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!apple!fox!portal!atari!apratt From: apratt@atari.UUCP (Allan Pratt) Newsgroups: comp.sys.ibm.pc Subject: Re: Turbo C portability from other C compilers (SUMMARY) Summary: summary Message-ID: <1887@atari.UUCP> Date: 15 Dec 89 18:41:07 GMT References: <1880@atari.UUCP> Organization: Atari Corp., Sunnyvale CA Lines: 109 I have been reminded of my obligation to post a summary as a followup to my question about Turbo C on the PC. Thanks to all who replied. The bottom line is that Turbo C is not a "wierd" compiler. It's perfectly straightforward and presents no unreasonable barriers to code portability. Some pointed out the "inherent" limit of 64K data structures on the PC. (I don't think it's "inherent," I think it's "easy." You *can* generate correct code for arbitrary-sized data structures on an 80x86, but it's hard and makes for biger, slower executables.) Also, the limitation of 16-bit int's, with no option for larger ones, makes it practically impossible to port from "traditional" (incorrect) UNIX programs. I guess I'm spoiled by Aztec C and GCC, which both have options for 16-bit or 32-bit int's on the 680x0. Here are selected excerpts from respondents. (I hope I wasn't expected to get their permission...) I've trimmed signatures etc.: please assume that opinions are those of the author, and not his organization. The responses are interesting in the variety of answers to the ANSI-ness question. ---------------------------------------------------------------------- From ames!ucsd!nprdc!malloy Thu Dec 14 07:05:19 1989 So far, I've only had three problems when porting software from the Suns and Vaxen at work to my PC using Turbo C: 1) Any program that depends on the Unix signals for part of its operation will need to have that part rewritten, because the PC does it differently. 2) A program which tries to declare storage in excess of 64K in a single variable chokes unless modified for the PC's architecture. This is a fault with the 80x86 architecture, not the compiler. 3) Some of the library function names are different. The most recent case was moving a file that had calls to random() and srandom() -- the Turbo C libraries had rand() and srand(), and a global replace was sufficient to clean up the problem. All the programs that I've ported that don't depend on any feature arising from the OS or hardware architecture have compiled and run with little if any tweaking. A friend of mine did run into one problem where he had to break up a file into separately compiling files because he filled one of the internal tables during the compile, but I thought it was stupid programming practice to have a program as one 273K source file, anyway. I'm not sure if it is fully ANSI compliant, and the version I have is not up to the most recent spec, having been released prior to it, but I believe that it is at least 90% compliant (hedging due to the manuals being not at work, but at home). ---------------------------------------------------------------------- From ames!pur-ee!jmoore Thu Dec 14 07:09:32 1989 I have been using Turbo-C since the first version and have found it to be quite friendly and as long as you can stay away from the PCisms it is quite traditional. I have easily ported TC code to MSC and the such with minor problems also. Programming for portability mostly depends on the programmer as much as anything. If you stay away from the ??isms (machine specific info) it will make things easier. ---------------------------------------------------------------------- From ames!harvard!genrad.com!somewhere!jpn Thu Dec 14 16:07:52 1989 >Secondly, is the PC's Turbo C an ANSI C compiler? Well, it's an almost-ANSI C compiler. It does prototypes, and it does ## and # operators in #defines. I'm not sure how close it really is with things like volatile and const (although the keywords are recognized). I know that it has several new keywords that would make it non-ANSI complient (far and near and huge: these are things for dealing with memory models and segmentation) but I think there is a command line flag for turning these things off. I know Turbo C doesn't claim ANSI status (__STDC__) with the default compiler flags, but I think it might if you turn off the incompatible extensions. ---------------------------------------------------------------------- From ames!harvard!spdcc!esegue!johnl Thu Dec 14 09:06:50 1989 Turbo C on the PC is a real ANSI compiler, give or take a few nits. It has some extensions that won't bother you unless you have a lot of variables with names like _ES. The library does not have all of the ANSI cruft, but does support all of the familiar unix routines and emulates many unix system calls. ---------------------------------------------------------------------- From: afscian@watmsg.waterloo.edu (Anthony Scian) >Secondly, is the PC's Turbo C an ANSI C compiler? No, and it never will be unless the calling convention is changed. The mechanism used for returning float, double, and struct/union types is not re-entrant and hence violates the pANSI standard. Same goes for MSC. WATCOM C7.0 is the only PC/DOS C compiler that can be considered the closest to pANSI compliant (i.e., __STDC__==1). Anthony