Re: Semantic Checking - C

johnvoltaire wrote:


> Hello! We need help.
>
> 1. We are trying to improve the semantic analysis of a particular
> compiler, and we need to identify the errors that compilers usually
> can or cannot detect. Please take time to review the following list of
> errors we've gathered and check if any or all of them belongs to the
> semantic checking routine during compilation/runtime. If you know a
> specific semantic error that we missed, we'll appreciate it if you
> could add the details.
>
> 2. The process we are planning to do is to make a static semantic
> checking of C programs so that these kind of semantic errors would not
> occur upon execution the program. This particular process is somewhat
> like we can call as a diagnostic procedure that will walkthrough the
> source code (without the necessity of running it) and see if any of
> the statements will violate any semantic rules.
>
> From what we've understand, static semantic checking refers to the
> analysis of expected program meaning or flow before
> compilation/execution, while dynamic semantic checking refers to the
> analysis during execution. Could anyone affirm on these?


static semantic checking is in the domain of static analysis. Yes, static
analysis checks programs' integrities without actually executing programs.
google "program static analysis", "static analysis" or "abstract
interpretation", you will find more details explanation.


>
> Is there anyone here that we could consult or discuss with regards to
> this subject?
>
> Good day to all and thanks in advance!
>
> Sincerely,
> John Voltaire


The following classifies all errors you listed.


A. it can be determined statically.
        1,2, 4, 5, 6, 7, 11, 12, 13, 14, 15, 16, 17, 18
B. it could partially be determined statically, and runtime check is
necessary to ensure free of errors.
   3, 8, 9
C. In general it could not be detected statically.
   10. 


Actually, GCC can detect most of errors in class A.


Neal


>
> Common semantic errors in C language:
>
> 1. Use of function without function prototypes
> 2. Code with no effect (dead code)
> 3. Division by zero
> 4. Use of functions and variables which are defined but not used
> 5. Use of functions and variables with defined arguments that are never
> used
> 6. Use of functions and variables that return either with or without
> any assigned value
> 7. Use of functions and variables that return values that are never
> used
> 8. Subscript out of bounds
> 9. Booleans that always evaluate true or evaluate false
> 10. Checking of infinite loops as well as loops that cannot be exited
> or entered
> 11. Statements that cannot be reached during execution
> 12. No identifiers or variables are used twice in the same block or
> scope
> 13. The number and types of arguments in a function call must be the
> same as the number and types of the prototypes
> 14. A return statement must not have a return value unless it appears
> in the function prototype that is declared to return a value
> 15. Break statements appear outside enclosing constructs where a break
> statement may appear
> 16. Elements of enumerated types are repeated
> 17. Variable names appear in the same lexical scope
> 18. Labels are repeated

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