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,FREEMAIL_FROM, INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,74b55538385b7366 X-Google-Attributes: gid103376,public From: "Vladimir Olensky" Subject: Ada safety road Was: Which is right ... Date: 1999/06/07 Message-ID: <928703068.617.98@news.remarQ.com>#1/1 X-Deja-AN: 486425221 References: <928083159.436.79@news.remarQ.com> <928174549.336.98@news.remarQ.com> <7iuqkc$ln6$1@nnrp1.deja.com> <928529202.956.79@news.remarQ.com> <928569312.951.42@news.remarQ.com> <7jb1l9$694$1@nnrp1.deja.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Complaints-To: newsabuse@remarQ.com X-Trace: 928703068.617.98 K3TLTKYJOA5C9C7F8C qube-02.us-ca.remarq.com Organization: Posted via RemarQ Communities, Inc. NNTP-Posting-Date: Sun, 06 Jun 1999 21:04:28 GMT Newsgroups: comp.lang.ada Date: 1999-06-07T00:00:00+00:00 List-Id: Robert Dewar wrote in message <7jb1l9$694$1@nnrp1.deja.com>... >And to repeat, since you keep repeating the subject, both >GNAT and OA are right here, and do what the RM intends! Sorry, It just didn't come up to my mind to change the subject. Even original subject was not very adequate to what I had in mind I really did not had intention on insisting which is better in following RM. I had other things in mind. I was just thinking about different aspects of providing some general kind of "foolproofness" to program written in Ada in places where RM define program behavior as erroneous. I think nobody would like to be on a plane that performed erroneous flight """' ' ' ^~\_+. Anyone would prefer to be accidentally on board of the wrong flight instead. One good aspect of Ada is that when it is impossible to provide compiler solution to some problems (due to implementation cost and some other reasons that may not be very obvious) LRM at least honestly specifies situations when erroneous execution is possible. But I see one problem here. All this information is scattered around RM. I think that to facilitate safety programming such info should be gathered into one paper with explanations why it was not possible to overcome such situations and it should contain many examples covering different aspects that leads to erroneous execution. There should be no indirect references ("other then ...."). Everything should be directly described and should be as simple as possible. I see it as some kind of "Ada safety programming roadmap". And of course such paper should be easily available online for all interested in it. So far I have not seen such document available online . If you crossing mine field and you do not have good map with red marks on it all your life depends on your luck :-) Such type of documents are usually top level documents in design of any safety critical system (at least it was in my experience). I recently put together all that staff from RM and I should mention that this list is not very short. So I was wondering if it is possible to do something on compiler level to make this list shorter. Almost five ears left since adoption of Ada 95 standard. Computing power has increased almost tenfold since then (CPU speed, memory access time, memory density etc.). Some things that were costly to implement then may have much less cost now. Here I would like to add one more thing. In many disputes Ada is described as mostly reliable language which allows to catch almost all errors at compile time and others at a run time by raising exceptions. This can create some kind of trap for those starting to use Ada ( to forget about cases of erroneous execution or not to pay attention to them) (e.g. typical comparisons between C&C++ and Ada pointers from which the reader may have wrong impression that Ada fully safe in this respect and as a result not to pay proper attention to that issue. For me the most safe in this area is Modula-3 for very well known reasons). Regards, Vladimir Olensky