Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!uwvax!oddjob!gargoyle!ihnp4!cbosgd!cwruecmp!hal!ncoast!allbery
From: allbery@ncoast.UUCP (Brandon Allbery)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Turbo C/Pascal, debugging
Message-ID: <2861@ncoast.UUCP>
Date: Sat, 11-Jul-87 21:23:02 EDT
Article-I.D.: ncoast.2861
Posted: Sat Jul 11 21:23:02 1987
Date-Received: Mon, 13-Jul-87 01:09:12 EDT
References: <719@imsvax.UUCP> <3256@oberon.USC.EDU>
Reply-To: allbery@ncoast.UUCP (Brandon Allbery)
Followup-To: comp.sys.ibm.pc
Organization: Cleveland Public Access UN*X, Cleveland, Oh
Lines: 41
As quoted from <3256@oberon.USC.EDU> by mlinar@poisson.usc.edu (Mitch Mlinar):
+---------------
| In article <719@imsvax.UUCP> paul@imsvax.UUCP (Paul Knight) writes:
| > What I like about Turbo Pascal, and I don't seem to be seeing these
| >features in Turbo C, are the checks on system errors at run time. A
| >number of things which used to drive me batty using state-of-the-art
| >Fortran compilers on mainframes never see the light of day in Turbo
|
| I don't argue with the fact that Turbo Pascal has more error checking than
| either Turbo C or Fortran. HOWEVER, this is more a fundamental difference
| between Pascal and C and NOT just a compiler nicety.
+---------------
May I also note that, since pointers and arrays are (almost) interchangeable
in C, checking array bounds will probably cause programs manipulating pointers
in a perfectly legal and correct way to blow up.
Example: In Pascal, you can not new(ptr) to get an arbitrarily-sized array.
(I haven't tried it, but you may be able to new(fixed-size-array).) In C,
this is easy: ptr = (ptrtype) calloc(numelts, sizeof *ptr). But, if you try
to bounds-check this, you either have to add huge amounts of code and tables
updated at runtime to show that "ptr" is an array of "numelts" elements AT
THE TIME OF THE CHECK (since next time it may be numelts + 1 elements), or
you decide it has to be a single element (thus making the program not work),
or you take the C route: no checking at all.
The best way to check C programs is the "safe C" approach: a C interpreter.
This, however, assumes that you have all the libraries to be linked in in
interpreter library form or in source.
Actually, it might be nice to have a "dcc" that compiles in code to load
and check tables of current allocations for variables and cause runtime
errors if you say "x = calloc(3, sizeof *x); printf("%lx\n", x[3]);". (A
common error, since you said 3 and the highest element is therefore 2.) This
is true of UN*X as well as DOS.
--
[Copyright 1987 Brandon S. Allbery, all rights reserved] \ ncoast 216 781 6201
[Redistributable only if redistribution is subsequently permitted.] \ 2400 bd.
Brandon S. Allbery, moderator of comp.sources.misc and comp.binaries.ibm.pc
{{ames,harvard,mit-eddie}!necntc,{well,ihnp4}!hoptoad,cbosgd}!ncoast!allbery
<>