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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,25aa3c7e1b59f7b5 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-01-09 01:58:19 PST Message-ID: <3C3C1438.FBF10FC3@baesystems.com> Date: Wed, 09 Jan 2002 09:58:16 +0000 From: Stuart Palin Organization: BAE SYSTEMS Avionics, Rochester X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: A case where Ada defaults to unsafe? References: <3C34BF2C.6030500@mail.com> <3C34D252.4070307@mail.com> <5ee5b646.0201040829.18db8001@posting.google.com> <3C35E733.6030603@mail.com> <3C35FE2A.9020802@mail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit NNTP-Posting-Host: rc2966.rochstr.gmav.gecm.com X-Trace: 9 Jan 2002 09:58:16 GMT, rc2966.rochstr.gmav.gecm.com Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!btnet-peer1!btnet-feed5!btnet!newreader.ukcore.bt.net!pull.gecm.com!rc2966.rochstr.gmav.gecm.com Xref: archiver1.google.com comp.lang.ada:18682 Date: 2002-01-09T09:58:16+00:00 List-Id: Nick Roberts wrote: > > "Simon Wright" wrote in message > news:x7vn0ztysj6.fsf@smaug.pushface.org... > > > I find it quite hard to imagine this scenario, I must say. > > > > We have a safety-related system where it is important that the > > extinguisher is set off as soon as possible and activating the gearbox > > alert takes sufficiently long that it can delay the extinguisher > > activation beyond tolerance[1]. And we are allowing a programmer to > > change this code without any process to ensure that the safety > > properties of the system aren't compromised? > > You are probably quite right! This is a failure of my example, rather than > of the point it was intended to illustrate. For many kinds of less > safety-critical Ada software such an elaborate software process is not > warranted, and my argument would apply better. > > > It does reinforce the point. You are wrong (you might have been right if the > changed version were the original and vice versa). I think the important point in Simon's message was: > > making subtle deductions about the **intent of the designer** from > > **details of the implementation** is a big mistake. If a designer is being 'clever' or has done something in a particular way for a good reason, then this should be explicitly documented (comments at least). It is a big mistake to **have to** deduce detailed intent by attributing subtle meanings to code. Relating to the current thread I think I understand where Hyman is coming from; but feel that ** if this is an issue ** for a particular system that it is not difficult to adopt 'house rule' that mandate using 'and then' and 'or else' (and accepting all the downside aspects). I think Hyman is mistaken to think that Ada is 'by default' a ** safe language **; it has features that enhance safety by preventing (or allowing the detection of) certain types of programming error. Even in subsets like SPARK it is quite possible to write unsafe programs (Simon's and Nick's posts illustrate this). Safety is a system property and software safety can not be assessed in total isolation from the system. Quite what makes a system ** unsafe ** will depend on the hazards facing the system and what are and are not permitted actions. My own pet peeve in Ada is the choice of comment token; A := very_long_name_B - very_long_name_C + very_long_name_D -- very_long_name_E - very_long_name_F; While thorough forms of testing should readily detect the 'missing' reference to E, it just seems silly to introduce the risk of a simple typo involving a commonly used mathematical symbol; especially when there seem to be plenty of (otherwise) unused symbols available. -- Stuart Palin Principal Software Engineer BAE SYSTEMS Avionics Ltd, Rochester G-NET 791 3364 mailto:stuart.palin@baesystems.com