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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,fee8802cc3d8334d X-Google-Attributes: gid103376,public X-Google-Thread: 10a146,fee8802cc3d8334d X-Google-Attributes: gid10a146,public From: Marin David Condic Subject: Re: Ada and Java. different behaviour. casting long to int problem. Date: 1999/06/23 Message-ID: <3770F79C.42132886@pwfl.com>#1/1 X-Deja-AN: 492968603 Content-Transfer-Encoding: 7bit Sender: condicma@bogon.pwfl.com References: <7jt2c0$vrb@drn.newsguy.com> <7k57vb$1ipf@drn.newsguy.com> <3766650F.705125B7@pwfl.com> <7k64t7$igo$1@its.hooked.net> <7k689a$ci2@drn.newsguy.com> <3766C842.E1EAB60A@pwfl.com> <7kp3f2$m9i$1@nnrp1.deja.com> Content-Type: text/plain; charset=us-ascii Organization: Pratt & Whitney Mime-Version: 1.0 Reply-To: diespammer@pwfl.com Newsgroups: comp.lang.ada,comp.lang.java.programmer Date: 1999-06-23T00:00:00+00:00 List-Id: Robert Dewar wrote: > This is unrealistic. The idea that safety critical software > depends on programmers doing the right thing on the basis of > "casual belief" is way off the mark. > Never said that. What I was aiming at was the issue of default semantics for arithmetic operations. Most of the time when a programmer writes "X := X + 1" he's off thinking that he is going to get the successor to X. It would be the unusual condition which would create an overflow (or wraparound or saturation) BTW: We do the intense verification specifically because fallible human beings often casually assume that X := X + 1 is going to generate the successor and someone had better test to find out what happens if it doesn't. > In fact an unanticipated overflow causing an exception may be > as dangerous, if not MORE dangerous than an ignored overflow > (Ariane 5 was a nice demonstration of this). > Yup. That's why I have said elsewhere that I think there should be different types with different semantics so that the appropriate behavior can be selected for the application in question. Example: Standard Integer semantics are fine for a bank balance program because halting the program with an exception is less harmful than wrapping around or saturating. Whereas, in most control applications, saturation is infinitely superior to either an exception or a wraparound. > In practice in safety critical software, formal verification > and certification techniques are used to ensure that NEITHER > event happens. > > Don't worry, when you fly on a plane, regardless of the language > used, you are not at the mercy of programmers doing *anything* > casually. Safety critical software just does not work this way! > I don't worry. I build this stuff for a living! :-) Because I do, I'm very cognizant of the fact that human beings make mistakes on a regular basis and that's why we go through multiple layers of very expensive verification before a control is ever allowed to fly a jet engine that is carrying people. Yet still, we design into it the "What if there is an error somewhere that we didn't catch?" strategy which guarantees safe and sane behavior "just in case". MDC -- Marin David Condic Real Time & Embedded Systems, Propulsion Systems Analysis United Technologies, Pratt & Whitney, Large Military Engines M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600 ***To reply, remove "bogon" from the domain name.*** Visit my web page at: http://www.mcondic.com/