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
From: "Marin David Condic, 561.796.8997, M/S 731-96" <condicma@PWFL.COM>
Subject: Re: Safety-critical development in Ada and Eiffel
Date: 1997/07/21
Message-ID: <97072110371803@psavax.pwfl.com>#1/1
X-Deja-AN: 258003789
Sender: Ada programming language <INFO-ADA@LISTSERV.NODAK.EDU>
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Vms-To: SMTP%"INFO-ADA@VM1.NODAK.EDU"
Newsgroups: comp.lang.ada
X-Vms-Cc: CONDIC
Date: 1997-07-21T00:00:00+00:00
List-Id: <comp.lang.ada>


Ken Garlington <kennieg@FLASH.NET> writes:
>> What does this have to do with the problem under discussion?  I agree that
>> this can happen, but why does the ability to enable and disable assertions
>> cause any new problems?
>
>Because I have seen compilers that generate correct code with one set of
>compiler options enabled, and a different (incorrect) set with a
>different
>set of options enabled. As with the timing issue above, I can do all of
>my testing with assertions enabled, and have no clue whether or not the
>code will still work after I disable those assertions (due to a compiler
>bug). Again, this is a Bad Thing for safety-critical systems.
>
    Let me ask a question about the way you work in your environment.
    I presume you have some group who is responsible for verification
    of whatever code you produce. Would they find it at all acceptable
    to change the contents of so much as one bit in an image without
    requiring some level of reverification of that image?

    We sort of tolerate *some* change, limited to a set of constants
    which need to be tuned for engine trim - sometimes overall trim
    for a type of engine, sometimes trim for a specific engine.
    (Depends on the project) But even then, the constants are given
    their own part number and are run through some abbreviated set of
    tests in the lab before being accepted as safe to send out the
    door.

    But the question of changing even a single word in the program
    image is unacceptable to our test group unless I can guarantee
    that by changing that word there is no conceivable way of causing
    the engine to come to harm or otherwise causing the control to
    malfunction. Since I can't do that, we never change an image in
    any way without reverification. Hence, verifying with compiler
    switch X set to "assertions enabled" then recompiling with switch
    X set to "assertions disabled" and presuming this is O.K. is not
    an option. Verification for us is also quite expensive and will
    eventually involve engine test stand time, so doing it twice is
    not economically viable.

    What I'd like to know is if we're unique in this requirement. Your
    IRS computers are also tasked with mission critical
    responsibilities and I'd like to get the thumbnail sketch as to
    what your verification and CM people find acceptable.

    MDC

Marin David Condic, Senior Computer Engineer     ATT:        561.796.8997
Pratt & Whitney GESP, M/S 731-96, P.O.B. 109600  Fax:        561.796.4669
West Palm Beach, FL, 33410-9600                  Internet:   CONDICMA@PWFL.COM
===============================================================================
    "You spend a billion here and a billion there. Sooner or later it
    adds up to real money."
        --  Everett Dirksen
===============================================================================