Re: Ada and Java. different behaviour. casting long to int problem.

[Marin David Condic <condicma@bogon.pwfl.com>]

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/