apratt@atari.UUCP (Allan Pratt) (12/14/89)
I don't normally read this group, so please respond by mail, not by posting. I am wondering if Turbo C is a "friendly," "traditional" C compiler. What I mean is, can you take programs written in other environments and compile them under Turbo C? UN*X is one environment which comes to mind, but there are lots of others. When you start with a program written somewhere else, do you find you have to hack and tune to get the thing to compile and run under Turbo C? Do you find that to have been because of Turbo C's idiosyncrasies, rather than those of the other environment? I'm asking because I have used the Turbo C compiler which is available in Germany for the Atari ST, and I have found it to be idiosyncratic. I know that it doesn't share its lineage with the PC version, but I do wonder if the PC version is like that. Secondly, is the PC's Turbo C an ANSI C compiler? ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
afscian@watmsg.waterloo.edu (Anthony Scian) (12/15/89)
In article <1880@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: >I don't normally read this group, so please respond by mail, not >by posting. [e-mail bounced and text has been deleted] >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 //// Anthony Scian afscian@watmsg.uwaterloo.ca afscian@watmsg.waterloo.edu //// "I can't believe the news today, I can't close my eyes and make it go away" -U2
apratt@atari.UUCP (Allan Pratt) (12/16/89)
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
darcy@druid.uucp (D'Arcy J.M. Cain) (12/16/89)
In article <32632@watmath.waterloo.edu> afscian@watmsg.waterloo.edu (Anthony Scian) writes: >The mechanism used for returning float, double, and struct/union >types is not re-entrant and hence violates the pANSI standard. I don't know about struct/union returns but I thought floats and doubles were re-entrant. Can you explain why they aren't. (Not doubting you, just honestly curious.) -- D'Arcy J.M. Cain (darcy@druid) | Thank goodness we don't get all D'Arcy Cain Consulting | the government we pay for. West Hill, Ontario, Canada | No disclaimers. I agree with me |