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,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public X-Google-Thread: fac41,2c6139ce13be9980 X-Google-Attributes: gidfac41,public From: Joachim Durchholz Subject: Re: Safety-critical development in Ada and Eiffel Date: 1997/07/26 Message-ID: <33D9B8F9.4693018C@munich.netsurf.de>#1/1 X-Deja-AN: 259152196 References: <33CD1722.2D24@calfp.co.uk> <33D24C91.C9730CBA@munich.netsurf.de> <33D71492.6F06@uk.ibm.com> X-Priority: 3 (Normal) Organization: ccn - computer consultant network GmbH Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-07-26T00:00:00+00:00 List-Id: Paul M Gover wrote: > > Joachim Durchholz wrote: > > Now *that* sounds bogus to me. The code should execute in exactly > > the > > same way, wether assertions are turned on or off. If you don't have > > enough confidence in the compiler to generate code that runs > > correctly, > > why do you use a compiler at all? > By definition, the code executes differently depending on whether > asserions > are turned on or off - because the assertion checking _is_ code! That's not what assertions are supposed to do. Of course assertions may themselves be buggy, but the only possibility here should be that an assertion signals an error where there is none. > In particular, there's likely to be some memory management going on in > an > OO system. Two possibilities: we could run out of memory in the > assertion, > or the memory management might take too long for some critical signal. 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.) 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. Of course the mechanism for reporting exceptions may interfere with the normal functioning of the user interface. (You can take the "exceptions don't affect execution" only so far.) > I currently support a program where switching the diagnostic trace on > breaks part of the user interface (since the program's correct, > I don't need to trace, so I don't need to fix the bug!?!). This depends. Is the diagnostic a debugging aid? Then you don't really have to fix it (at least if you are confident that everything will work in the absence of diagnostics). If the diagnostics are part of the finished product, you'll have to fix it, of course. But then this is not what assertions are intended for (in Eiffel). 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. Regards, Joachim -- Please don't send unsolicited ads.