* C.A.R. Hoare on liability @ 2002-06-17 16:09 Wes Groleau 2002-06-19 16:14 ` Mike Silva 2002-06-21 11:55 ` Robert Dewar 0 siblings, 2 replies; 15+ messages in thread From: Wes Groleau @ 2002-06-17 16:09 UTC (permalink / raw) Tying together two recent threads, a quote from "The Emperor's Old Clothes": ... we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them would be disastrous. I note with fear and horror that even in 1980, language designers and users ahve not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law. -- Wes Groleau http://freepages.rootsweb.com/~wgroleau ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: C.A.R. Hoare on liability 2002-06-17 16:09 C.A.R. Hoare on liability Wes Groleau @ 2002-06-19 16:14 ` Mike Silva 2002-06-19 16:57 ` Darren New 2002-06-19 18:03 ` Larry Kilgallen 2002-06-21 11:55 ` Robert Dewar 1 sibling, 2 replies; 15+ messages in thread From: Mike Silva @ 2002-06-19 16:14 UTC (permalink / raw) Wes Groleau <wesgroleau@despammed.com> wrote in message news:<3D0E09BA.A492AA3D@despammed.com>... > Tying together two recent threads, > a quote from "The Emperor's Old Clothes": > > ... we asked our customers whether they wished us > to provide an option to switch off these checks > in the interests of efficiency on production runs. > Unanimously, they urged us not to--they already knew > how frequently subscript errors occur on production > runs where failure to detect them would be disastrous. > I note with fear and horror that even in 1980, language > designers and users ahve not learned this lesson. I sure don't understand this part. It sounds as if "our customers" were saying that, yes, we know how important it is to have checks turned on even in production code, but, notwithstanding that knowledge, we simply can't be trusted to leave them on ourselves, and so we must be forced by the compiler to keep them turned on. Very odd! > In any respectable branch of engineering, failure > to observe such elementary precautions would have > long been against the law. Yep! ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: C.A.R. Hoare on liability 2002-06-19 16:14 ` Mike Silva @ 2002-06-19 16:57 ` Darren New 2002-06-19 18:03 ` Larry Kilgallen 1 sibling, 0 replies; 15+ messages in thread From: Darren New @ 2002-06-19 16:57 UTC (permalink / raw) Mike Silva wrote: > I sure don't understand this part. It sounds as if "our customers" > were saying that, yes, we know how important it is to have checks > turned on even in production code, but, notwithstanding that > knowledge, we simply can't be trusted to leave them on ourselves Or "It's so important to keep them on that it's so unlikely we'll want to turn them off that it's not worth us paying you to develop the option to do so." -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. ** http://home.san.rr.com/dnew/DNResume.html ** ** http://images.fbrtech.com/dnew/ ** My brain needs a "back" button so I can remember where I left my coffee mug. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: C.A.R. Hoare on liability 2002-06-19 16:14 ` Mike Silva 2002-06-19 16:57 ` Darren New @ 2002-06-19 18:03 ` Larry Kilgallen 2002-06-19 17:54 ` Wes Groleau 1 sibling, 1 reply; 15+ messages in thread From: Larry Kilgallen @ 2002-06-19 18:03 UTC (permalink / raw) In article <27085883.0206190814.67fc4825@posting.google.com>, mjsilva697@earthlink.net (Mike Silva) writes: > Wes Groleau <wesgroleau@despammed.com> wrote in message news:<3D0E09BA.A492AA3D@despammed.com>... >> Tying together two recent threads, >> a quote from "The Emperor's Old Clothes": >> >> ... we asked our customers whether they wished us >> to provide an option to switch off these checks >> in the interests of efficiency on production runs. >> Unanimously, they urged us not to--they already knew >> how frequently subscript errors occur on production >> runs where failure to detect them would be disastrous. >> I note with fear and horror that even in 1980, language >> designers and users ahve not learned this lesson. > > I sure don't understand this part. It sounds as if "our customers" > were saying that, yes, we know how important it is to have checks > turned on even in production code, but, notwithstanding that > knowledge, we simply can't be trusted to leave them on ourselves, and > so we must be forced by the compiler to keep them turned on. Very > odd! How about: We are never going to turn them off, so please don't make our user interface any more complicated than it already is. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: C.A.R. Hoare on liability 2002-06-19 18:03 ` Larry Kilgallen @ 2002-06-19 17:54 ` Wes Groleau 2002-06-20 13:05 ` Marin David Condic 0 siblings, 1 reply; 15+ messages in thread From: Wes Groleau @ 2002-06-19 17:54 UTC (permalink / raw) > > I sure don't understand this part. It sounds as if "our customers" > > were saying that, yes, we know how important it is to have checks > > turned on even in production code, but, notwithstanding that > > knowledge, we simply can't be trusted to leave them on ourselves, and > > so we must be forced by the compiler to keep them turned on. Very > > odd! > > How about: > > We are never going to turn them off, so please don't make > our user interface any more complicated than it already is. How about: We know how stupid it would be to turn them off, and we don't want to risk having them turned off by the inevitable idiot that will slip past even the best employment screening. or _We_ understand, but we don't want to take the chance that _management_ will order them turned off under pressure from _our_ customer to squeeze one more millisecond out of the cycle time. -- Wes Groleau http://freepages.rootsweb.com/~wgroleau ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: C.A.R. Hoare on liability 2002-06-19 17:54 ` Wes Groleau @ 2002-06-20 13:05 ` Marin David Condic 2002-06-21 14:31 ` Wes Groleau 0 siblings, 1 reply; 15+ messages in thread From: Marin David Condic @ 2002-06-20 13:05 UTC (permalink / raw) I'm confused about where this is going. Are we talking about creating some sort of "User Selectable Speed Option" in an application that allows the user to turn off runtime checks? (Never seen that.) In which case, if the "customer" doesn't want it, then you don't put one of those in. Or is the notion that the "customer" wants the program image built with all runtime checks enabled - implying that the compiler should never allow them to be turned off? If it is the latter, it seems intuitively obvious to even the most casual observer that unless 100% of all customers everywhere are *insisting* on full runtime checking (Never had one who went beyond "It needs to work all the time...") that a developer needs to have the option of turning the checks off for whatever percentage of the customers out there want to insist that you do so. So maybe I don't get where C.A.R. Hoare is going with this - you want to be "customer driven"? Or is it more important that you build "good" software - which *can* be done with runtime checks turned off when necessary? (Surely, he can't be convinced that it is *never* necessary to turn off runtime checks, can he?) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Wes Groleau" <wesgroleau@despammed.com> wrote in message news:3D10C557.11C9DBC2@despammed.com... > > How about: > > We know how stupid it would be to turn them off, > and we don't want to risk having them turned off > by the inevitable idiot that will slip past > even the best employment screening. > > or > > _We_ understand, but we don't want to take the > chance that _management_ will order them turned > off under pressure from _our_ customer to squeeze > one more millisecond out of the cycle time. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: C.A.R. Hoare on liability 2002-06-20 13:05 ` Marin David Condic @ 2002-06-21 14:31 ` Wes Groleau 2002-06-21 16:47 ` Marin David Condic 0 siblings, 1 reply; 15+ messages in thread From: Wes Groleau @ 2002-06-21 14:31 UTC (permalink / raw) > So maybe I don't get where C.A.R. Hoare is going with this - you want to be > "customer driven"? Or is it more important that you build "good" software - > which *can* be done with runtime checks turned off when necessary? (Surely, > he can't be convinced that it is *never* necessary to turn off runtime > checks, can he?) I have no idea what he thinks now. :-) But in the quote, he states that he (or his company) suggested an option to turn off the checks and the customers said "No!" The other extreme is a language that does not have the checks, and when offered a "helper app" that might do _some_ of the checks, some users say "No!" Seems like Ada has a nice balance between those extremes. -- Wes Groleau http://freepages.rootsweb.com/~wgroleau ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: C.A.R. Hoare on liability 2002-06-21 14:31 ` Wes Groleau @ 2002-06-21 16:47 ` Marin David Condic 0 siblings, 0 replies; 15+ messages in thread From: Marin David Condic @ 2002-06-21 16:47 UTC (permalink / raw) That would be my opinion - provide checks as the default and if I really, really, really need that extra bit of speed on some segment of code, I'll turn them off manually. For most programmers, I wouldn't even tell them how to do it because they'd never need it, but it should be there as a back door. (But that's the kind of thing you do as a policy for the app development - stipulate what options are the norm for the project.) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Wes Groleau" <wesgroleau@despammed.com> wrote in message news:3D1338A5.A34E6C7A@despammed.com... > > Seems like Ada has a nice balance between those > extremes. > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: C.A.R. Hoare on liability 2002-06-17 16:09 C.A.R. Hoare on liability Wes Groleau 2002-06-19 16:14 ` Mike Silva @ 2002-06-21 11:55 ` Robert Dewar 2002-06-21 20:45 ` Robert I. Eachus 2002-06-22 2:55 ` SteveD 1 sibling, 2 replies; 15+ messages in thread From: Robert Dewar @ 2002-06-21 11:55 UTC (permalink / raw) Wes Groleau <wesgroleau@despammed.com> wrote in message news:<3D0E09BA.A492AA3D@despammed.com>... > Tying together two recent threads, > a quote from "The Emperor's Old Clothes": > > ... we asked our customers whether they wished us > to provide an option to switch off these checks > in the interests of efficiency on production runs. > Unanimously, they urged us not to--they already knew > how frequently subscript errors occur on production > runs where failure to detect them would be disastrous. > I note with fear and horror that even in 1980, language > designers and users ahve not learned this lesson. > In any respectable branch of engineering, failure > to observe such elementary precautions would have > long been against the law. Three comments First, runtime checks can be deadly if you have not done proper analysis of how they can be handled, since they can turn trivial errors that would not intefere with overall correct function into disasters (Ariane5 is an example of this in action). Second, in safety critical code you often turn run time checks off, because you rely on other means to ensure that these checks can never fail. See for example the work that Praxis has done in proving programs to be exception free. With such a proof in hand, run time checks can be a menace for certification since you have a whole bunch of useless deactivated code. Third, there are situations in which the extra overhead from runtime checks, small though it may be, is unacceptable. It is no use saying to someone, sorry we know that if the checks could be turned off, you could use Ada just fine, but we have decided in Ada 0X that it was a terrible idea to allow people to do this, so you will have to use C instead. As to customers who can't trust themselves to follow their own procedures, I have no sympathy whatever. Procedures should be enforced by a combination of review and tools, and failure to put in the effort for such enforcement is sloppy workmanship in my view. For example, I would think that project files that describe the required compilation options should be under very strict configuration control, and not something that can casually be modified by someone who does not know what they are doing. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: C.A.R. Hoare on liability 2002-06-21 11:55 ` Robert Dewar @ 2002-06-21 20:45 ` Robert I. Eachus 2002-06-22 13:14 ` Robert Dewar 2002-06-22 2:55 ` SteveD 1 sibling, 1 reply; 15+ messages in thread From: Robert I. Eachus @ 2002-06-21 20:45 UTC (permalink / raw) Robert Dewar wrote: > Three comments > > First, runtime checks can be deadly if you have not done proper > analysis of how they can be handled, since they can turn trivial errors that > would not intefere with overall correct function into disasters (Ariane5 is > an example of this in action). I agree with the point, but not the example. For Ariane 4, the analysis was carried out, and whether or not you agree with the final decision for Ariane 4, the decision was well thought out. The disaster was that the Araine 4 analysis was carried out absent the Ariane 5 requirements for political reasons, and the Ariane 5 requirements analysis was never done. Was it the first TriAda where I first heard that the problem with reuse is that the Mark II tank is not the same as the Mark I tank? > Second, in safety critical code you often turn run time checks off, > because you rely on other means to ensure that these checks can never fail. > See for example the work that Praxis has done in proving programs to be > exception free. With such a proof in hand, run time checks can be a menace for > certification since you have a whole bunch of useless deactivated code. Agreed, but see above. The analysis must be redone for reuse. > Third, there are situations in which the extra overhead from runtime checks, > small though it may be, is unacceptable. It is no use saying to someone, sorry > we know that if the checks could be turned off, you could use Ada just fine, > but we have decided in Ada 0X that it was a terrible idea to allow people to > do this, so you will have to use C instead. Agreed, and I really like the methods you use in GNAT. If code depends on a particular exception, explicitly turn it on in the code. If code depends on some exception not occcuring, turn the check off. That way changes in global settings don't affect the correctness of the program. > For example, I would think that project files that describe the required > compilation options should be under very strict configuration control, and > not something that can casually be modified by someone who does not know > what they are doing. Definitely right. But the problem is that if you drop the configuration change request on some VP's desk for his signature, you are likely to get hauled on the carpet if not fired. Or worse yet, the VP will sign off without doing the engineering analysis needed. Look at what happened on Challenger. The engineer on the spot refused to sign off, and a corporate VP two time zones away--and not a licensed professional engineer--signed off on the boosters and faxed the OK to NASA. (NASA should not have gone along with this. But this was the first shuttle flight where an engineer was not in the NASA chain of command. Beggs had been asked to step aside due to some accounting irregularities on government programs while he was on the Board of Directors at Lockheed. The acting head of NASA was not an engineer, and by the time Beggs was cleared, it was too late.) ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: C.A.R. Hoare on liability 2002-06-21 20:45 ` Robert I. Eachus @ 2002-06-22 13:14 ` Robert Dewar 2002-06-22 13:36 ` Jack Flynn 2002-06-22 16:47 ` Mark Biggar 0 siblings, 2 replies; 15+ messages in thread From: Robert Dewar @ 2002-06-22 13:14 UTC (permalink / raw) "Robert I. Eachus" <rieachus@attbi.com> wrote in message news:<3D1390D0.7040709@attbi.com>... > I agree with the point, but not the example. For Ariane 4, the analysis > was carried out, and whether or not you agree with the final decision > for Ariane 4, the decision was well thought out. The disaster was that > the Araine 4 analysis was carried out absent the Ariane 5 requirements > for political reasons, and the Ariane 5 requirements analysis was never > done. I disagree. Here you have a case in the Ariane4 code where a check was being made at runtime which had the quality that if the check failed, disaster would occur. There are two possibilities 1. In the Ariane4 code, it was demonstrated that this check could never fail. In that case, the check should not have been there. 2. In the Ariane4 code, it was NOT demonstrated that this check could never fail. In that case, they were just lucky that no Ariane4 blew up. I will repeat. You should NEVER have a runtime check in your code where it is the case that failing the check is a more serious situation than not doing it at all. Casually putting in checks is very likely to generate such cases. My understanding of the Ariane case is that this check was casually put in, in other words it was put in WITHOUT any analysis that said this check was needed. Deployed code should not have such checks. If you leave checks on throughout an Ada program, then a complex analysis is required to ensure that if any check fails, it is properly handled in a manner that does not do more damage than failing the check. If you do not leave checks on, then a complex analysis is required to ensure that nothing serious fails that would have been caught by a check. In the absence of any careful analysis, it is not clear whether it is better to leave on all checks or not. The important thing is to realize that in the absence of a careful analysis, turning all checks on is not necessarily safer than leaving them off. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: C.A.R. Hoare on liability 2002-06-22 13:14 ` Robert Dewar @ 2002-06-22 13:36 ` Jack Flynn 2002-06-22 16:47 ` Mark Biggar 1 sibling, 0 replies; 15+ messages in thread From: Jack Flynn @ 2002-06-22 13:36 UTC (permalink / raw) "Robert Dewar" <dewar@gnat.com> wrote in message news:5ee5b646.0206220514.55f8cf9a@posting.google.com... > > My understanding of the Ariane case is that this check was casually put in, > in other words it was put in WITHOUT any analysis that said this check was > needed. Deployed code should not have such checks. > In the Ariane IV case, analysis was done to convince themselves that they did not have a "generic software fault". The checks were to trap faulty hardware and get a failed channel offline to prevent actuator force fights or other interference with the unfailed channel. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: C.A.R. Hoare on liability 2002-06-22 13:14 ` Robert Dewar 2002-06-22 13:36 ` Jack Flynn @ 2002-06-22 16:47 ` Mark Biggar 2002-06-23 15:47 ` Robert I. Eachus 1 sibling, 1 reply; 15+ messages in thread From: Mark Biggar @ 2002-06-22 16:47 UTC (permalink / raw) Robert Dewar wrote: > > "Robert I. Eachus" <rieachus@attbi.com> wrote in message news:<3D1390D0.7040709@attbi.com>... > > > I agree with the point, but not the example. For Ariane 4, the analysis > > was carried out, and whether or not you agree with the final decision > > for Ariane 4, the decision was well thought out. The disaster was that > > the Araine 4 analysis was carried out absent the Ariane 5 requirements > > for political reasons, and the Ariane 5 requirements analysis was never > > done. > > I disagree. Here you have a case in the Ariane4 code where a check was being > made at runtime which had the quality that if the check failed, disaster > would occur. There are two possibilities > > 1. In the Ariane4 code, it was demonstrated that this check could never fail. > In that case, the check should not have been there. > > 2. In the Ariane4 code, it was NOT demonstrated that this check could > never fail. In that case, they were just lucky that no Ariane4 blew up. > > I will repeat. You should NEVER have a runtime check in your code where it > is the case that failing the check is a more serious situation than not doing > it at all. Casually putting in checks is very likely to generate such cases. > > My understanding of the Ariane case is that this check was casually put in, > in other words it was put in WITHOUT any analysis that said this check was > needed. Deployed code should not have such checks. No the situation was more complicated then that. Ariane 4 had, like most rocket systems, redundant hardware sets each with its own, independent sensor set. Careful analysis was done that showed that given the possible flight profiles, the only way the code should see an overflow was if the sensor suite was packed up and sending bogus data. The check for overflow was thus used to detect hardware problems and the exception raised was to notify the upper control code that that particular hardware set was offline and to ignore it. Ariane 5 had a very different flight profile including much higher accelerations. So when the software was reused, without rechecking the analysis against the new Ariane 5 flight profile, it saw a real overflow that didn't have anything to do with hardware faults, so all the redundent hardware suites overflowed and threw an exception all at the same time. This put the rocket out of control and I believe it was destroyed by the range safety system. So both the check and the exception were reasonable and correct for the Ariane 4 and would not have crashed it. So it was reusing the code without redoing the analysis or even testing it against the new flight profile that cause the problems, not the check in the code. This problem would have arisen regardless of the language used. -- Mark Biggar mark.a.biggar@attbi.com ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: C.A.R. Hoare on liability 2002-06-22 16:47 ` Mark Biggar @ 2002-06-23 15:47 ` Robert I. Eachus 0 siblings, 0 replies; 15+ messages in thread From: Robert I. Eachus @ 2002-06-23 15:47 UTC (permalink / raw) Mark Biggar <mark.a.biggar@attbi.com> wrote in message news:<3D14AA34.E8FFBBBB@attbi.com>... > So both the check and the exception were reasonable and > correct for the Ariane 4 and would not have crashed it. So it > was reusing the code without redoing the analysis or even > testing it against the new flight profile that cause the > problems, not the check in the code. This problem would have > arisen regardless of the language used. Right, in fact the actual situation was worse than that. I won't go into all the gory details, but part of the assumption of hardware failure was to dump raw data from the intertial guidance system on the buss to the engine control system. This caused the engines to deflect enough to cause the "stack" to break up, and at this point the range safety officer had to destroy the rocket. Where were the limits on the engine deflection that should have prevented this? They were set for the Ariane 4. The Ariane 5 stack was more fragile, and the engines more powerful. So if the Arianne 4 software developers had gotten permission to put in a local exception handler for the piece of software that failed on the Ariane 5, the Ariane 5 would have made it past 38 seconds into the flight--and then would have destroyed itself if it hit wind shear at a higher altitude. As far as I am concerned, that was the real disaster. The complex path that started the actual failure involved an exception raised because the Ariane 5 exceeded one of the physical limits for the Ariane 4. But there were dozens of Ariane 4 physical parameters built into the software which could have been the primary cause of failure. The actual failure only ran into three of them. (Horizontal movement from point of launch in the first 40 seconds of flight, stack moment of inertia, maximum engine deflection.) ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: C.A.R. Hoare on liability 2002-06-21 11:55 ` Robert Dewar 2002-06-21 20:45 ` Robert I. Eachus @ 2002-06-22 2:55 ` SteveD 1 sibling, 0 replies; 15+ messages in thread From: SteveD @ 2002-06-22 2:55 UTC (permalink / raw) "Robert Dewar" <dewar@gnat.com> wrote in message news:5ee5b646.0206210355.3533be8f@posting.google.com... [snip] > > First, runtime checks can be deadly if you have not done proper analysis > of how they can be handled, since they can turn trivial errors that would > not intefere with overall correct function into disasters (Ariane5 is > an example of this in action). > Of course the errors detected by runtime checks might not be trivial errors as well. I can recall a case where an occasional overflow in calculations in an old FORTRAN program caused some very large machinery to move to a very awkward position. As you say there is no substitute for doing a proper analysis. SteveD ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2002-06-23 15:47 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-06-17 16:09 C.A.R. Hoare on liability Wes Groleau 2002-06-19 16:14 ` Mike Silva 2002-06-19 16:57 ` Darren New 2002-06-19 18:03 ` Larry Kilgallen 2002-06-19 17:54 ` Wes Groleau 2002-06-20 13:05 ` Marin David Condic 2002-06-21 14:31 ` Wes Groleau 2002-06-21 16:47 ` Marin David Condic 2002-06-21 11:55 ` Robert Dewar 2002-06-21 20:45 ` Robert I. Eachus 2002-06-22 13:14 ` Robert Dewar 2002-06-22 13:36 ` Jack Flynn 2002-06-22 16:47 ` Mark Biggar 2002-06-23 15:47 ` Robert I. Eachus 2002-06-22 2:55 ` SteveD
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox