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,b78c363353551702
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.68.234.38 with SMTP id ub6mr4426802pbc.2.1340392511984;
        Fri, 22 Jun 2012 12:15:11 -0700 (PDT)
MIME-Version: 1.0
Path: 
 l9ni7873pbj.0!nntp.google.com!news1.google.com!volia.net!news2.volia.net!feed-A.news.volia.net!news.musoftware.de!wum.musoftware.de!newsfeed.x-privat.org!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: about the new Ada 2012 pre/post conditions
Date: Fri, 22 Jun 2012 14:15:02 -0500
Organization: Jacob Sparre Andersen Research & Innovation
Message-ID: <js2g7s$8dm$1@munin.nbi.dk>
References: <jrsjr7$uuo$1@speranza.aioe.org>
 <4f0d55a9-83e1-44fe-8943-0c73a34a594d@googlegroups.com>
 <js00mr$cuc$1@munin.nbi.dk> <js01ol$76g$1@adenine.netfront.net>
NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net
X-Trace: munin.nbi.dk 1340392509 8630 69.95.181.76 (22 Jun 2012 19:15:09 GMT)
X-Complaints-To: news@jacob-sparre.dk
NNTP-Posting-Date: Fri, 22 Jun 2012 19:15:09 +0000 (UTC)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
X-RFC2646: Format=Flowed; Response
Date: 2012-06-22T14:15:02-05:00
List-Id: <comp.lang.ada>

"Jeffrey Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message 
news:js01ol$76g$1@adenine.netfront.net...
> On 06/21/2012 01:37 PM, Randy Brukardt wrote:
>>
>> "Hard-coded checks" prevent the compiler from doing call-site 
>> optimizations
>> and tools from doing much of anything. They should be avoided. The 
>> solution
>> is the pragma I showed earlier:
>>
>>     pragma Assertion_Policy (Pre =>  Check,
>>                                             Pre'Class =>  Check,
>>                                             Static_Predicate =>  Check,
>>                                             Dynamic_Predicate =>  Check);
>>
>> put in *every* reusable package spec. They still can suppress the checks 
>> by
>> manually deleting the pragma, but it will render command line switches 
>> and
>> IDE checkboxes ineffective. And if they do delete the pragma, they've
>> intentionally shot themselves in the foot, and it is no longer your (the
>> package maintainers) problem. (Unless of course they want to spend extra
>> $$$.)
>
> Interesting. I wasn't aware of checks that can't be overridden by compiler 
> options, and will be surprised if most compilers don't include a way to 
> override these as well.

A compiler option is essentially equivalent (or should be) to a 
configuration pragma. Nested pragmas override any outer pragmas (or 
switches). The same is true for Suppress/Unsuppress.

You might be right, but that would be evil in the extreme. This pragma is 
used in the same way that Unsuppress is used for other checks, and 
overrriding an explicit Unsuppress would be very, very bad (as it would 
cause code to malfunction). The same is true here.

                                 Randy.