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!news.eternal-september.org!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Ada 2012 Constraints (WRT an Ada IR) Date: Mon, 5 Dec 2016 16:06:29 -0600 Organization: JSA Research & Innovation Message-ID: References: <92ed75e9-baae-455c-9e34-53348dc6eaef@googlegroups.com> <03847fd7-5699-48de-bb3c-ef5512398f26@googlegroups.com> <3ef819e8-55f7-4ef7-9f37-77e6abc33f98@googlegroups.com> <47366b42-c0a3-41bf-a44a-5241c109d60f@googlegroups.com> NNTP-Posting-Host: rrsoftware.com X-Trace: franka.jacob-sparre.dk 1480975529 32026 24.196.82.226 (5 Dec 2016 22:05:29 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Mon, 5 Dec 2016 22:05:29 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:32623 Date: 2016-12-05T16:06:29-06:00 List-Id: wrote in message news:alpine.DEB.2.20.1612050922450.22845@debian... ... >On the other hand, there are systems, where a malfunction is worse than no >function (e.g., a secure router -- better no communication than allowing >attackers to pass through the security perimeter). In such cases, it may >be wise do perform Assert-checking even in production executables. My opinion is that the vast majority of systems are in this category, especially if one considers each task (here using "task" in its English meaning as a block of work) separately. Every system that I've personally worked on has been in this category (anti-spam filter - a bug causes a message to be quarantined, which provides a path to reproducing the bug; web server - a bug causes nothing useful to be returned, better than allowing a security hole and returning, say, a password file; Ada compiler - a bug usually causes the compiler to crash rather than producing incorrect code that might cause problems; Claw Builder - a bug usually causes buggy generated code, which breaks the contract with the user). Most such systems need an "others" handler to ensure that one failing task (again, English meaning) doesn't cause the entire system to fail. Such handlers need some sort of reporting system so they're not silently covering bugs. I also tend to disagree about suppressing/ignoring checks and predicates. In my experience, if a check or predicate or assertion is too expensive to run in the production system, it's also too expensive to run in testing. Simple checks should never be turned off -- a visible bug is always better than an invisible bug. (Moreover, compilers are always getting better about eliminating such checks, in which case many checks aren't made at all.) Expensive checks, if one has to have them at all, need to be managed separately from assertions/constraints/predicates -- one would only want to turn them on if all else has failed, and that clearly needs to be separate from the suppress/ignore mechanism. (Most of the systems I've worked on have a runtime management setup for tracing/assertions, where they get managed by functional areas as needed for figuring out the problem at hand.) Randy.