🚀 go-pugleaf

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