Run-time Checks for C

[Doug Gwyn]

In article <10113 at umn-cs.CS.UMN.EDU> raghavan at umn-cs.cs.umn.edu (Vijay Raghavan) writes:
>   I made a casual statement in a local bulletin board to the effect that
>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. 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.) 
>   Comments? Treat this as a question of academic interest. Ignore 
>considerations of efficiency on architectures which don't support run-time
>checking mechanisms. Also assume that all support library functions (in
>particular, malloc, calloc etc.) have been written in a way as to support
>these checks, wherever possible. 

Although few existing implementations of C provide such checks, there are
a few that do.  The one I most remember was (is?) marketed under the name
"Safe C".  The forthcoming C standard is quite specific about what must
be allowed and what is "illegal" (not an official term; officially there
are varieties of behavior called "unspecified", undefined",
"implementation defined", etc.).  Anything that is not definitely allowed
could be diagnosed at compile time or at run time.  To support run-time
checks, an implementation would usually have to access data objects via
descriptors (known to old-timers as "dope vectors"), with a lot of
overhead.  Some hardware allows efficient implementation of things like
null or uninitialized pointer dereferencing, etc.  Unless every data
object can be allocated in a separate segment, there isn't much that can
be done about efficient bounds checking.