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,abd508cccb4803ea X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-06-21 04:55:52 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: dewar@gnat.com (Robert Dewar) Newsgroups: comp.lang.ada Subject: Re: C.A.R. Hoare on liability Date: 21 Jun 2002 04:55:50 -0700 Organization: http://groups.google.com/ Message-ID: <5ee5b646.0206210355.3533be8f@posting.google.com> References: <3D0E09BA.A492AA3D@despammed.com> NNTP-Posting-Host: 205.232.38.243 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1024660552 19604 127.0.0.1 (21 Jun 2002 11:55:52 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 21 Jun 2002 11:55:52 GMT Xref: archiver1.google.com comp.lang.ada:26549 Date: 2002-06-21T11:55:52+00:00 List-Id: Wes Groleau 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.