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!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Tests in a software release Date: Tue, 14 Nov 2017 17:55:10 -0600 Organization: JSA Research & Innovation Message-ID: References: Injection-Date: Tue, 14 Nov 2017 23:55:14 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="17229"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: feeder.eternal-september.org comp.lang.ada:48895 Date: 2017-11-14T17:55:10-06:00 List-Id: "Dmitry A. Kazakov" wrote in message news:osvvds$s97$1@gioia.aioe.org... ... > No. The contract requires Constraint_Error propagation. Disabling checks > breaks that. I agree. > The intention of allowing checks being disabled was to allow manual > optimization in very few cases when the preconditions are known to be > stronger than specified. The source of this knowledge is unknown, it is up > to the code maintainer to assert it. For this reason disabling checks > cannot be the rule in contrary to what Victor suggested. I think the main reason for allowing disabling checks had to do with the practicalities of computer systems in the late 1970's and early 1980's when this part of Ada was originally defined. Back then, memory and CPU time was at a premium, optimization technology (especially that regarding checks, which few languages had) was not very advanced, and disabling checks could make the difference between being able to run a program and not. Early versions of Janus/Ada disabled all checks just so that more space was available for symbols (the first CP/M versions of Janus/Ada had only 56K of RAM to run in!). But in modern compilers, optimization technology is much more advanced, checking optimization is something that hundreds of man hours has been spent on in every Ada compiler, there is plenty of CPU for general computation, so checks should be disabled only in very limited contexts if at all. Pretty much I only know of three cases: (1) profiling has shown that a particular routine is too slow, and suppressing checks for that single routine improves the performance of the application; (2) a tool like SPARK has been used to prove exception absence for a program with detailed code-level verification requirements; suppressing the checks that raise those exceptions already proved to be absent cuts the verification requirements; (3) a routine implementing something like saturation math is being implemented, and suppressing the range and overflow checks makes a cheaper implementation. And personally think that (1) and (2) are better handled in the compiler by careful use of subtypes (and in the case of (2), additional warnings if an unexpected check is generated). And it's really unclear if (3) is better than just handling the exception(s) (and using Unsuppress to ensure no one turns off the checks). Thus I think all style guides should treat pragma Suppress much like Goto and Abort, requiring a detailed justification for any usage at all. (Indeed, I'd much rather use a Goto, it's much less likely to cause a problem.) Randy.