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,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,59dddae4a1f01e1a X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: Software Safety (was: Need help with PowerPC/Ada and realtime tasking) Date: 1996/06/08 Message-ID: #1/1 X-Deja-AN: 159199807 references: <4p4trk$tc5@watnews1.watson.ibm.com> organization: The World Public Access UNIX, Brookline, MA newsgroups: comp.lang.ada Date: 1996-06-08T00:00:00+00:00 List-Id: In article , Robert Dewar wrote: >I certainly agree that it is unfortunate that the term correct has been >hijacked, however, it is tilting at windmills to try to change this now >(sort of like my efforts to prevent the misuse of moot and oxymoron :-) You tilt at "moot" and "oxymoron". I tilt at "correct". We all have our pet peeves, I suppose. If we think we can actually *change* any such usage, we're either prophets or deranged (usually the latter). ;-) Natural language changes, not always for the better. >In the case of softare, correct and reliable are of course NOT the same. >Reliability includes the specificatoin being correct, and of course >we have no way of proving a specification correct, at most we could >prove it consistent, but that might simply mean it is consistently wrong! Indeed. >Actually as specifications get more formal, it often gets harder and harder >to determine if it is correct. Try looking at the formal definition done >by the EEC for Ada 83, it is two fat telephone books of mathematical >formula -- and there is no way of ensuring it is correct [in fact, as >would be expected for what is essentially a huge program that has never >been run, it is not correct]. There are two things at work here: (1) as one gets more formal, one gets a deeper understanding, and eliminates bugs, and (2) as one gets more formal, one gets further removed from the intuitive notion of what the software really ought to do, and this causes bugs. >On the other hand, a program that trivially departs from its spec (background >of the GUI is slightly different shade of green than specified for example) >may still be completely reliable even though it is not correct. True, but you have to admit that this is less important than the other way 'round, where software obeys its spec but does some damage. I will tolerate when somebody *insists* on the correct shade of green, if they also insist on things that really *do* matter. And one shouldn't forget that about half of the bugs really are the kind of "plain old bugs" where the software doesn't do what the spec says it should, and the spec is, in fact, right, and everybody agrees it's a bug. - Bob