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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,9da298537a16487e X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1995-01-28 03:02:03 PST Path: swrinde!howland.reston.ans.net!agate!newsxfer.itd.umich.edu!zip.eecs.umich.edu!panix!cmcl2!thecourier.cims.nyu.edu!thecourier.cims.nyu.edu!nobody From: dewar@cs.nyu.edu (Robert Dewar) Newsgroups: comp.lang.ada Subject: Re: Run-time checking and speed Date: 28 Jan 1995 01:03:05 -0500 Organization: Courant Institute of Mathematical Sciences Message-ID: <3gcmmp$of@gnat.cs.nyu.edu> References: <3ev16u$ojc@pong.lasc.lockheed.com> <3f3deb$4us@gnat.cs.nyu.edu> <3fa2pk$kbi@felix.seas.gwu.edu> <3fu902$6al@felix.seas.gwu.edu> <3g1eku$lmd@gnat.cs.nyu.edu> <3g8hpf$pn@rational.rational.com> NNTP-Posting-Host: gnat.cs.nyu.edu Date: 1995-01-28T01:03:05-05:00 List-Id: Kent Mitchell asks why one might need to turn off checks in certified code. Sure the checks will be executed, but presumably you are doing the checks so that if the check fails, then you do something. It is the something that is a problem. Suppose you do constraint error checking in some routine, just to catch incorrect input from somewhere else in the program, and you have a handler that defends against bad input. How will you do coverage testing of the handler, if in fact, as one might hope, there aren't any bad calls. Not only compiler generated checks are the issue here. Suppose you write: if x > 10 and y > 10 then -- Don't know if this can ever happen, but just in case ... y := x - 10; -- readjust to acceptable range end if; such code might be appropriate defensive programming in some situations, but might cause trouble if certification requires coverage testing. There are three possibilities in a case like this: 1. You can find a case where the condition is triggered. Fine trigger it for the coverage test. 2. You can prove it never happens. Fine, remove the check 3. You can't prove it never happens, all your attempts to find the case fail, but you can't complete an actual proof. Case 3 is the tough one, and shows why coverage testing can sometimes be a double edged sword. And I have definitely seen situations in which checking has been disabled precisely because any code conditioned on the checks is impossible or difficult to coverage testing. I am not particuarly defending this state of affairs, or the absolute requirement for coverage testing, just pointing out the situation :-)