Free Trial

Safari Books Online is a digital library providing on-demand subscription access to thousands of learning resources.

Share this Page URL
Help

13.6 Static Analysis Techniques and Tool... > 13.6.2 Extended Static Checking - Pg. 347

CHAPTER 13 Also, the same errors that a static type checker would quickly catch are not discovered until run time. Errors such as variable typos would result in run-time exceptions. Debugging might even become more of a hassle, as errors that do get reported could have their root cause elsewhere. Of course, this problem can also exist in some static type checking techniques. Languages and Security 347 13.6.2. Extended Static Checking Consider for a moment the problem with array bounds checking briefly mentioned in Sec- tion 13.6.1. It was stated that bounds checking requires a dynamic type checker, because a static type checker could not determine (with the pro- vided rules) all of the possible values an array index variable could take and whether or not it violated the array's typing rule. That does not mean that it could not be checked statically, only have their pros and cons. Cormac Flanagan and Kenneth Knowles have developed a novel approach to overcome these slight problems [30]. Their approach uses both static type checking and dynamic checking in order to enjoy the ben- efits of both. The hybrid type checker described by Flanagan and Knowles should be applicable to many languages, as it was developed using an extension of the -calculus. In hybrid type checking, the compilation phase can end in one of three states. Two states refer to the statically decidable well-typed and ill-typed phases. These programs can be decided 100% at run time. However, some programs may not be statically determined to fall into one of these two states. In this case, the compilation phase ends in an undetermined state, and dynamic checks are inserted into the code in order to verify safety at run time. These are referred to as sub- tle programs and can fall into two states: those