From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,b284f3c6f5dea395,start X-Google-Attributes: gid103376,public From: dewar@cs.nyu.edu (Robert Dewar) Subject: Correction to previous post Date: 1996/04/03 Message-ID: #1/1 X-Deja-AN: 145584240 organization: Courant Institute of Mathematical Sciences newsgroups: comp.lang.ada Date: 1996-04-03T00:00:00+00:00 List-Id: Someone pointed out to me that an example I previously posted was wrong, I must have cut-and-pasted the wrong versoin, GRRR! Here is the example I meant to post: with Text_IO; use Text_IO; procedure S is Sum : Integer; begin for J in 1 .. 10 loop Sum := Sum + J; end loop; Put_Line (Integer'Image (Sum)); end; <> And once again, my point was that on some systems, the above program will give the right result, and therefore pass exhaustive testing, even though it has a blatant bug. The point is that even exhaustive testing is not enough to prove that a program meets its specifications. Now of course white box testing using use-def chaining, could with the addition of tools that pointed out uninitialized paths, find this error, but of course white-box testing is not an option open to the ACVC testing. Actually exhuastive coverage and path testing would be a very difficult task on a program as complex as a compiler for a complex language. The effort would be huge, and the trouble is that compilers are fluid enough that the testing would be rapidly out of date, even if you could afford to do it. I certainly am not aware of any commercial compiler for Ada, C++, or even C that has been subjected to complete coverage and path testing (including of course use-def path testing, since that i is what is involved here).