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,7a58195927ccb785 X-Google-Attributes: gid103376,public From: Ken Garlington Subject: Re: Not intended for use in medical devices Date: 1997/05/12 Message-ID: <33775001.4B3B@lmtas.lmco.com>#1/1 X-Deja-AN: 241156955 References: <3.0.32.19970504232023.006f5c8c@mail.4dcomm.com> <5kl8g4$fcb@bcrkh13.bnr.ca> Organization: Lockheed Martin Tactical Aircraft Systems Newsgroups: comp.lang.ada Date: 1997-05-12T00:00:00+00:00 List-Id: One comment on Dr. Dewar's discussion on object code analysis (with which I agree): A good part of the object code analysis can (and should be) _automated_ with appropriate tools. In particular, it is gratifying to see that some Ada compiler vendors are starting to include object code coverage testing tools in their products. I would like to think that the inclusion of Annex H has helped to promote the development of such tools in the Ada community for safety-critical systems. Robert Dewar wrote: > > Kaz says > > <<< for avoiding inspections of the object code. In a safety critical system, an > incorrect translation of a correct program could lead to death, injury or > property damage. There is no other way to catch this sort of error except to > compile the code and then inspect the results of the translation.>> > > I certainly agree with this. In fact I never heard of a people using a > process for generating safety-critical code that did not require this > kind of review, and certainly the formal standards require this. > > < the first place, since in the process of reviewing object code, you have to > acquire an understanding of the program at the machine language level anyway. > I can at least appreciate where this extreme viewpoint is coming from.>> > > I strongly disagree with this, and find it surprising that anyone would > suggest this. The review of the object code is just one of many aspects > of the total methodology required for safety critical code. Another > important aspect is more emphasis on the use of formal methods in > developing and analyzing the code at a high level, and these are > very much language dependent, and make assembly language quite useless. > > The object code review is oriented to making sure that the code reflects > the high level intent correctly, and the objectives used in analyzing > this code are directly derived from the original high level code. This > is why Annex H in the RM requires Ada compilers to provide assistance > in correlating the object output to the source (see annex H if you have > not read it!) > > How many of Ada's advantages over something like C are still relevant when you > have to inspect the object code instruction by instruction? > > All of them, and in fact they are probably more relevant than in other > domains. Eliminating all possibilities of error from a program is > achieved by a layered approach, and the help that an Ada compiler > gives in smoking out typing errors etc, and the help that the high > level Ada semantics give in forumulating appropriate conditions for > verification etc are of *especially* important value in SC systems. > > Also, see annex H which is oriented towards requiring that Ada tools > have suitable facilities. For example, a validated C compiler may not > even have a capability at all for examining the generated assembly code. > But a 100% conforming Ada compiler (including conformance to Annex H) > MUST have such a capability. For example, the -S and -g switches in > GNAT that generate assembly language annotated with source line and > label information is not just a nice-to-have feature in the context > of annex H, it is a *required* feature. -- LMTAS - The Fighter Enterprise - "Our Brand Means Quality" For job listings, other info: http://www.lmtas.com or http://www.lmco.com