Re: newbie: general compilers question: static checking

Neil Zanella <nzanella@cs.mun.ca> writes:


> I have seen the words "static checking" in the context of compilers
> several times as something typically done in between the parsing and
> intermediate code generation phases of the compiler. Could anyone
> please explain to me what static checking is?


"Static checking" usually means any checking that is (or can be) done
by inspecting the program text, but without running the program on
some input data. What rules can be checked statically vs. dynamically
depends on the programming language.


In the context of compilers, "static checking" means checking that
happens at compile time (or perhaps at link time), but not at run time.
But it is also possible to do static checking in separate tools; lint is
a simple example. My company (SofCheck, Inc.) makes tools (separate
from a compiler) for doing static checking of things like
array-index-out-of-bounds (also known as buffer overflow), which are
normally done at run time (if at all!). (We also make compilers.)


>... Also, is it a front-end issue or a back-end issue? Seems like a
>front-end issue to me since it seems to be language dependent. Seems
>to me like static checking is part of semantic analysis.


Yes, it is usually considered a front end issue, and is normally
considered part of semantic analysis. In most compiler designs, the
back end does not print out error messages, or prints out only a few
obscure kinds of error messages -- most static checking is considered
part of the front end.


> I think static checking has to do with checking type compatibility of
> assignment, arithmetic, and other operators. Perhaps someone can confirm
> this with me. I am not sure why this is so but some texbooks also call
> the following static checking:
>
> - checking that break statements do not appear outside enclosing
> constructs where a break statement may appear
> - checking that elements of enmerated types are not repeated
> - checking that variable names do not appear in the same lexical scope
> - checking that labels are not repeated


Yes, all of the above are "static checking", presuming they happen at
compile time. Of course, in a dynamically-typed language, type
compatibility is not checkable statically, in general.


> So, static checking seems to encompass a variety of semantic checks.
> In general, how do I tell whether a check done by the compiler falls
> under the category of static checking, and what is the relevance of
> the word static in the words static checking?


"Static" = "not moving", as in "we're not running the program" (yet).


> Perhaps someone can elaborate on static checking.
>
> In particular, I would like to know what the relationship between
> semantic analysis and static checking is. It would appear to me
> that the two terms could almost be used interchangeably. Is
> this correct?


Yes, almost interchangeably. But semantic analysis would include things
like when you say "X := 1;", the compiler needs to figure out which
thing called "X" are you referring to. (Again, presuming this is known
at compile time in the language.) I'd call that "static analysis".
What I'd call "static checking" is making sure that X refers to
*something* and is not ambiguous. As you say, *almost* the same thing.


- Bob

Return to the comp.compilers page.
Search the comp.compilers archives again.