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 <>