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 04:12:16 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!fu-berlin.de!uni-berlin.de!ppp-2-217.cvx1.telinco.NET!not-for-mail From: "Nick Roberts" Newsgroups: comp.lang.ada Subject: Re: A case where Ada defaults to unsafe? Date: Wed, 9 Jan 2002 11:11:12 -0000 Message-ID: References: <3C34BF2C.6030500@mail.com> <3C34D252.4070307@mail.com> <5ee5b646.0201040829.18db8001@posting.google.com> <3C35E733.6030603@mail.com> <3C35FE2A.9020802@mail.com> <3C3C1438.FBF10FC3@baesystems.com> NNTP-Posting-Host: ppp-2-217.cvx1.telinco.net (212.1.137.217) X-Trace: fu-berlin.de 1010578333 28059235 212.1.137.217 (16 [25716]) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Xref: archiver1.google.com comp.lang.ada:18684 Date: 2002-01-09T11:11:12+00:00 List-Id: "Stuart Palin" wrote in message news:3C3C1438.FBF10FC3@baesystems.com... > ... > 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. I agree with this principle in a big way. However, for a lot of Ada code (maybe not flight management code), there are always going to be situations where the designer is not available, and the documentation and/or comments do not cover a particular design decision in the code. Then it is, unfortunately, necessary to make deductions about the intent of the designer from details of the implementation. > 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). But Hyman and I can argue against such house rules (and I do!). > 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. I suspect Hyman wouldn't put Ada's safety in quite such stark terms. I think he was trying to say that Ada's features are normally safe by default, rather than that the language as a whole is somehow magically safe (and so programs written in Ada will never fail). My experience is that the biggest number, and worst kind, of 'bugs' in a safety-critical system are introduced long before the coding stage. No kind of coding can eliminate these bugs. [This is why the strategy of hedging with multiple codings (based on one specification) horrifies me so much, but that's another argument.] > 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. Hmm. How about: A := B + C; \~~~@@@^^^$$$^^^@@@~~~\ comment here :-) NB: I use a German server which is pretty good, but (in common with most Usenet servers, I gather) it doesn't get everything posted to comp.lang.ada; I didn't get Simon's most recent reply to me in this thread. So if my comments appear disjointed in this way, you know why. :-( ;-) -- Best wishes, Nick Roberts