wang@pilchuck.data-io.com (Frank Wang) (08/29/87)
We are designing a special purpose compiler for a new product. It seems
not very difficult to make it work. But testing is a problem to us now.
How can I make sure that no invalid syntax or other errors are not validated
by this compiler? Are there any books or articles about this?
Frank Wang
[If you use a compiler generator like yacc you can be reasonbly sure that the
language that it parses is the same as the one defined by the grammar. Beyond
that, I've not seen much work about making sure that all errors are caught by
the compiler; people seem to be more concerned about making sure that correct
programs compile correctly than that incorrect programs are all failed
correctly. -John]
--
Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.ARPA
Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | cca}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers. Meta-mail to ima!compilers-requestjohnl@ima.UUCP (09/18/87)
wang@pilchuck.data-io.com (Frank Wang) writes: > We are designing a special purpose compiler for a new product. It seems > not very difficult to make it work. But testing is a problem to us now. > How can I make sure that no invalid syntax or other errors are not validated > by this compiler? Are there any books or articles about this? Build a solid library of test cases of both valid and invalid code. Save the listings, and have some system for automatically running all the tests and comparing them with the listings. Design the tests to exercise everything thoroughly. If you notice some 'tricky case' while writing the compiler, put in tests to exercise it. For *every* bug the compiler ever has, put in a test case to exercise it, because old bugs are likely to show up again. It helps to add some switches to the compiler to make it print out various 'internal' things in the listings. Especially useful is generated code and symbol table information. This way you can check that things are really being done right inside, rather than having to check the indirect consequences of internal operations. We did this here at Cullinet, and it really gets the bugs out. Dale -- Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.ARPA Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | cca}!ima Please send responses to the originator of the message -- I cannot forward mail accidentally sent back to compilers. Meta-mail to ima!compilers-request