Re: ensuring full semantic checker coverage?

David Chase <chase@theworld.com>
23 Mar 2003 22:27:44 -0500

          From comp.compilers

Related articles
ensuring full semantic checker coverage? rossb@audiomulch.com (Ross Bencina) (2003-03-22)
Re: ensuring full semantic checker coverage? chase@theworld.com (David Chase) (2003-03-23)
Re: ensuring full semantic checker coverage? qjackson@shaw.ca (Quinn Tyler Jackson) (2003-03-24)
Re: ensuring full semantic checker coverage? rossb@audiomulch.com (Ross Bencina) (2003-03-30)
| List of all articles for this month |

From: David Chase <chase@theworld.com>
Newsgroups: comp.compilers
Date: 23 Mar 2003 22:27:44 -0500
Organization: Little or none
References: 03-03-138
Keywords: testing
Posted-Date: 23 Mar 2003 22:27:43 EST

Ross Bencina wrote:


  >To some degree the checks will be dispersed in the source
  >code, as I may need/want to implement the checks in multiple passes.


I might use an attribute grammar to get rid of the
thinking-about-multiple-passes problem, but that's not necessarily an
answer to your question.


  >My current plan is to build a database (some sort of tagged textfile)
  >with separate items for each assertion that the checker must test,
  >give each of these assertions an ID, then embed these IDs in comments
  >with the source code that implements each check. That way I can write
  >a script that crossreferences every required check to the code that
  >performs it. Perhaps the error message text for each check might also
  >form part of this approach.


I would go beyond comments, and put the tags into executable code, so
that you might (with the setting of a switch) record which checks were
applied and how they were resolved, perhaps including which line they
were applied at. This is a little bit of infrastructure in the
beginning, but it lets you write a set of tests that are supposed to
exercise checks, verify that the tests exercise what they claim to
test, and verify that they continue to do so after a code change.
Depending upon your audience, it might or might not hurt to
cross-reference error messages to the relevant line in the standards
documentation.


  >Another approach I can think of is to somehow organise the code so
  >that it follows the order of the sections in the specification, and
  >annotate each check in the code with the relevent specification
  >section numbers.


I'm less enthusiastic about this, mostly because you say "somehow"
(which means you're not sure, and I'm not sure myself) and because I
can see that actually tracing the rules that you execute will give you
something more valuable.


David Chase


Post a followup to this message

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