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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Simon Clubley Newsgroups: comp.lang.ada Subject: Re: Tests in a software release Date: Thu, 26 Oct 2017 17:30:03 -0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: Injection-Date: Thu, 26 Oct 2017 17:30:03 -0000 (UTC) Injection-Info: reader02.eternal-september.org; posting-host="a613d2dcfb37876af4c66087250fbb02"; logging-data="13024"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX183IDA9nT1CSaUefwJBRH6TbCpqpRXQRFM=" User-Agent: slrn/0.9.8.1 (VMS/Multinet) Cancel-Lock: sha1:2Gc05aXHJx4fQBVCeghgCWCH+ug= Xref: news.eternal-september.org comp.lang.ada:48597 Date: 2017-10-26T17:30:03+00:00 List-Id: On 2017-10-25, Victor Porton wrote: > Do you agree that a release (that is software for which debugging was > finished) should have integer overflow tests but not array out of bounds > tests (because array out of bounds is always a programming error, but > integer overflow may happen in an innocent program)? > No way should they ever be disabled. You only _think_ that debugging is finished. :-) Leave them enabled and have a failsafe handler do whatever is needed either to shut things down or to recover in a controlled manner. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world