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,f039470e8f537101 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-07-22 01:18:27 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!headwall.stanford.edu!newshub.sdsu.edu!elnk-nf2-pas!newsfeed.earthlink.net!newsfeed.news2me.com!uio.no!newsfeed1.e.nsc.no!nsc.no!nextra.com!news2.e.nsc.no.POSTED!53ab2750!not-for-mail Sender: leifm@huldreheim.huldreskog.no Newsgroups: comp.lang.ada Subject: Re: Ariane5 FAQ References: <1058799152.775376@master.nyc.kbcfp.com> <1058810510.375902@master.nyc.kbcfp.com> <1058813341.841940@master.nyc.kbcfp.com> <1058816605.566685@master.nyc.kbcfp.com> From: Leif Roar Moldskred Message-ID: <86ispvasza.fsf@huldreheim.huldreskog.no> User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: 80.212.78.191 X-Complaints-To: news-abuse@telenor.net NNTP-Posting-Date: Tue, 22 Jul 2003 10:04:23 MEST X-Trace: news2.ulv.nextra.no 1058861063 80.212.78.191 Date: 22 Jul 2003 10:03:21 +0200 Xref: archiver1.google.com comp.lang.ada:40612 Date: 2003-07-22T10:03:21+02:00 List-Id: Hyman Rosen writes: > Vinzent Hoefler wrote: > > Well, one way or another - it did. It did exactly what is was supposed > > to do. > > No matter how many times people on this newsgroup repeat this, > it will not become true. The code was written on the assumption > that a certain parameter would never reach a particular value. That's not quite correct. It was a limit, not an assumption. The programmers didn't just assume that the argument would never exceed the limit, they verified that this was in fact a real limit. > Its behavior under the contrary assumption was left unspecified. > It certainly did not do "what it was supposed to do" once the > assumption was violated. The system pretended that a hardware > error had happened. When the fundamental boundaries of your software's design specification is violated, there's no way it can "do what it's supposed to do." By the definition of design specification, anything a software is "supposed to do" lies within the boundaries of the specification. The software performed to spec, which is the only sensible way of saying it "did what it was supposed to do." If a tank drives onto an ordinary road-bridge and the bridge collapses under it, nobody is going to say that the bridge was flawed, or that the engineers who built the bridge had made an error. The bridge was completely fine - it just wasn't built to carry a tank. It is the tank commander's fault for driving out on the bridge without making sure it would bear. -- Leif Roar Moldskred