Re: Semantic Checking - C

Tommy Thorn <foobar@nowhere.void>
3 Feb 2005 22:44:51 -0500

          From comp.compilers

Related articles
Semantic Checking - C johnvoltaire@gmail.com (johnvoltaire) (2005-01-30)
Re: Semantic Checking - C nmm1@cus.cam.ac.uk (2005-02-03)
Re: Semantic Checking - C torbenm@diku.dk (2005-02-03)
Re: Semantic Checking - C jeremy.wright@microfocus.com (Jeremy Wright) (2005-02-03)
Re: Semantic Checking - C jacob@jacob.remcomp.fr (jacob navia) (2005-02-03)
Re: Semantic Checking - C neal.wang@gmail.com (Neal Wang) (2005-02-03)
Re: Semantic Checking - C foobar@nowhere.void (Tommy Thorn) (2005-02-03)
Re: Semantic Checking - C hannah@schlund.de (2005-02-11)
| List of all articles for this month |

From: Tommy Thorn <foobar@nowhere.void>
Newsgroups: comp.compilers
Date: 3 Feb 2005 22:44:51 -0500
Organization: Compilers Central
References: 05-01-098
Keywords: debug, semantics
Posted-Date: 03 Feb 2005 22:44:51 EST

There is only so much heuristics can do. Better results can be had when
a bit of user annotation is added. Many project do this, Linus' sparse
checker is one such example.


It's quite common to write a general macros which when instantiated
results in unused variables, unreached code, lots of constant
expressions, etc. and without a richer annotation you going to get a lot
of false negatives, turning the warnings into a nusance rather than a
help (just like gcc moronic complaints about "a && b || c").


> Common semantic errors in C language:


A subset of them are considered static (syntax or type) errors and are
already caught be most compilers:


> 1. Use of function without function prototypes
  > 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




These are nearly never occur statically:


> 3. Division by zero
  > 8. Subscript out of bounds




These are no always errors (think parameterizable programs). Some are
even very common (5 & 7)


  > 2. Code with no effect (dead code)
  > 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
  > 9. Booleans that always evaluate true or evaluate false
  > 11. Statements that cannot be reached during execution
  > 12. No identifiers or variables are used twice in the same block or
  > scope


This is not an error, except maybe in 1st year students programs (the
"cannot be entered" is an instance of unreachable code ~ 2):


  > 10. Checking of infinite loops as well as loops that cannot be exited
  > or entered


Tommy


Post a followup to this message

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