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.4 required=5.0 tests=BAYES_50,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,885dab3998d28a4 X-Google-Attributes: gid103376,public From: dewar@schonberg.cs.nyu.edu (Robert Dewar) Subject: Re: Ariane 5 failure Date: 1996/10/05 Message-ID: #1/1 X-Deja-AN: 187747739 references: <96100111162774@psavax.pwfl.com> <32555A39.E38@lmtas.lmco.com> organization: New York University newsgroups: comp.lang.ada Date: 1996-10-05T00:00:00+00:00 List-Id: Matthew said "> Buyers of mission-critical software should think very carefully before they > commit any financial resources to implementing a software system that > requires checks be turned off. I'd say take your money instead to Las > Vegas: your odds for success are better there." To the extent that checks are used for catching hardware failures this might be true, but in practice the runtime checks of Ada are not a well tuned tool for this purpose, although I have seen programs that work hard to take more advantage of such checks. For example: type My_Boolean is new Boolean; for My_Boolean use (2#0101#, 2#1010#); so that 1 bit errors cannot give valid Boolean values (check and see if your compiler supports this, it is not required to do so!) However, to the extent that checks are used to catch programming errors, I think that I would prefer that a safety critical system NOT depend on such devices. A programming error in a checks on program may indeed result in a constraint error, but it may also cause the plane to dive into the sea without raising a constraint error. I find the second outcome here unacceptable, so the methodology must simply prevent such errors completely. Indeed if you look at safety critical subsets for Ada they often omit exceptions precisely because of this consideration. After all exceptions make the language and compiler more complex, and that itself may introduce concerns at the safety critical level. Note also that exceptions are a double edged sword. An exception that is not handled properly can be much worse than no exception at all. If you have a section of code doing non-critical calculations (e.g. how much time to wait before showing the movie in the main cabin), it really does not matter too much if that calculation overflows and shows the movie a bit early, but if it causes an unhandled exception that wipes out the entire passenger control system, and turns out all the reading lights etc. that can be much worse. Even in a safety critical system, there will be calculations that are relatively unimportant. For example, a low priority task may cause an overflow. If ignored, an unimportant result is simply wrong. if not ignored, the handoling of the exception mayh cause that low priority task to overrun its CPU slice, and cause chaos elsewhere. As Ken says, checks are not a magic wand. They are a powerful tool, but like any tool, subject to abuse. A chain saw with a kickback guard on the end is definitely a safer tool to use, especially for an amateur, than one without (something I appreciate while clearing paths through the woods at my Vermont house), but it does not mean that now the tool is a completely safe one, and indeed a real expert with a chain saw will often feel that it is safer to operate without the guard, because then the behavior of the chainsaw is simpler and more predictable.