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-Thread: 103376,ad06d2d7cb045687 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.74.201 with SMTP id w9mr7609192pbv.0.1328579219479; Mon, 06 Feb 2012 17:46:59 -0800 (PST) MIME-Version: 1.0 Path: lh20ni268793pbb.0!nntp.google.com!news1.google.com!eweka.nl!lightspeed.eweka.nl!194.134.4.91.MISMATCH!news2.euro.net!newsfeed.x-privat.org!news.jacob-sparre.dk!pnx.dk!jacob-sparre.dk!ada-dk.org!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Silly and stupid post-condition or not ? Date: Mon, 6 Feb 2012 19:46:55 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <82wr86fzos.fsf@stephe-leake.org> <5af407fc-2868-44ca-84d2-c51a2a64104d@o4g2000pbc.googlegroups.com> <82k445fu9n.fsf@stephe-leake.org> <82ty36urik.fsf@stephe-leake.org> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1328579218 7211 69.95.181.76 (7 Feb 2012 01:46:58 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 7 Feb 2012 01:46:58 +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 Date: 2012-02-06T19:46:55-06:00 List-Id: "Robert A Duff" wrote in message news:wccobtdfgz9.fsf@shell01.TheWorld.com... > "Randy Brukardt" writes: > >> The postcondition (and precondition) moves this "contract" information to >> where it belongs (on the specification). > > Right. That's what makes a precondition better than simply putting > a pragma Assert at the start of the procedure body. > >>... That allows the compiler to take >> advantage of that information, and in many cases completely eliminate the >> associated checks (just like the compiler can eliminate a large >> proportion >> of constraint checks). Like constraint checks, well-written contracts >> should >> never need to be turned off... > > I don't agree. There are definitely cases when constraint checks > should be turned off. Likewise preconditions. If you say > "Never turn off checks", you're really saying "Never write > an assertion that is too expensive in production, even > though it might be helpful in testing and debugging", > which is clearly counter-productive. I would indeed argue that. More accurately, what I would argue is that any assertion that is too expensive to "use in production" be kept completely separate from the rest, and I'd suggest that it generally be turned off (unless absolutely needed). I've done this in my programs by simply commenting them out; they're only inserted when the problem that they are intended to detect shows up a second time. (That doesn't happen much.) I could see using some other mechanism to keep them separate; possibly going so far as to using a dynamic method to turn them on or off. This has always been one of my biggest complaints with Assertions; all or nothing is insufficient control; it's bad enough that I've never seen any real value to pragma Assert. (I'd rather use if statements controlled from a global package than to use a single compiler switch for such detection.) >>...(as always, it's like taking off the seatbelts >> when you leave the garage...). > > I don't buy this analogy (nor the similar one about life jackets and > sailboats). Seatbelts often save lives and reduce injuries > when something goes wrong. Preconditions (etc) don't cause > programs to give correct answers when something goes wrong > -- they just detect the wrongness. Turning off constraint checks make a program erroneous, and thus the program can return wrong answers without any notice. Back in the CP/M/MS-DOS-1 days, we used to have this problem a lot, especially by accessing non-existent variants. And a lot of those problems only showed up in production. Today, this sort of thing is a security problem - constraint checks at least bound the problem to at worse a denial-of-service problem, much less of a problem than allowing a buffer overflow that allows anything to be executed. I admit that is less of a problem for preconditions and the like, but I think the same holds true -- particular if the correctness checks were removed from the code in favor of the preconditions. > By the way, I find that when I (at first) think I want a > pre/post, it's usually better expressed as a subtype predicate. > My favorite new feature of Ada 2012. I agree. I originally thought that predicates were a better solution to the problem than pre/post/invariants. I still do for most uses, but of course whenever multiple parameters are involved you have to use a precondition instead. Randy.