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: fac41,2c6139ce13be9980 X-Google-Attributes: gidfac41,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public From: WhiteR@nospamplease.CRPL.Cedar-Rapids.lib.IA.US (Robert S. White) Subject: Re: Safety-critical development in Ada and Eiffel Date: 1997/07/28 Message-ID: <5rh12t$jl0$1@flood.weeg.uiowa.edu>#1/1 X-Deja-AN: 259603337 References: <33CD1722.2D24@calfp.co.uk> <33D24C91.C9730CBA@munich.netsurf.de> <33D71492.6F06@uk.ibm.com> <33D9B8F9.4693018C@munich.netsurf.de> Organization: Does not want airplanes to fall out of the sky! Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-07-28T00:00:00+00:00 List-Id: In article <33D9B8F9.4693018C@munich.netsurf.de>, joachim.durchholz@munich.netsurf.de says... >Plus the assertion themselves will take time to check, which influences >timing. >I'm not in the hard real-time business (and have never been), so I might >be grossly off the mark. What I currently think is that no harm should >result if the code runs faster after disabling assertion checking. (Some >informed people in this group have claimed otherwise, but I haven't seen >convincing arguments why this should be the case.) I hope you never have to do safety-critical hard real-time programming with more than a very few tasks running. You have never hear of a deadlock? Race condition? Sure you try to design to avoid such things, but you can never be sure that you have really successsfully avoided all timing sensitivities until you _test_ for them! The cold HARD rule is that if the machine code changes, then regression tests _must_ be done. > >Checking assertions (in the Eiffel sense) must not have observable >effects, except that the program may run slower (or similar irrelevant >differences). There are some style guidelines and hard rules that >enforce this. Not a suitable guard for hard real-time! Just what is the protection mechanism for this "must not"? Who validates Eiffel compiler object code to not have any "observable effect" when release code turns off assertion checks? >The possibility to switch off assertion checking without >affecting the program's semantics is an *axiom* in Eiffel; the language >and the guidelines go to great lengths to achieve this. But it has not convinced me that it (assertions one during development, off later for the released version) are suitable for hard real-time without doing a set of regression tests that would expose timing sensistivity problems. The FAA with DO-178B would be very unhappy that all of the object code paths are not thoroughly tested in the final released code version. _____________________________________________________________________ Robert S. White -- An embedded systems software engineer