Run-time Checks for C

[Wayne A. Throop]

> raghavan at umn-cs.CS.UMN.EDU (Vijay Raghavan)
> the C language definition doesn't really preclude any implementation from
> doing certain run-time checks (for array bounds, type checking, referring
> contents of uninitialized pointer variables &c), it's just that most
> (okay, all!) implementations don't do any such checking because of efficiency
> reasons.

Not all.  Saber-C and (possibly misremembered) Integral-C are examples
of C language systems that do extensive run-time checking.  

> Now I'm not sure that this statement is really true (I mean I'm not
> sure that sufficient information can always be passed to the compiler for it
> to generate code for meaningful run-time checks.)

The compiler can generate checks, but for C (unlike other languages) this
involves having pointers carry around valid range limit information.  Thus,
the performance penalty is pretty severe.  Further, languages such as
Pascal and Modula allow a much better modeling of intent by use of subranges,
so that some errors can be found much sooner than they would be found in
C (if they would be found at all).  But even with C's handicaps in this
regard, a range-checking version of C is a very, VERY valuable tool to use
in conjunction with exhaustive excersize of the software.

Further, if your C language system won't perform range or other runtime
checks optionally, (or for that matter... even if it does) you should
insert sanity-checking assertions into the code to use during unit and
integration testing.  It makes finding the source of errors SO much
easier, and costs so little.  It also nicely documents the assumptions
made by the code.

--
The use of COBOL cripples the mind;  its teaching should, therefore,
be regarded as a criminal offense.
                                        --- Edsgar Dijkstra
-- 
Wayne Throop      <the-known-world>!mcnc!rti!xyzzy!throopw