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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.182.241.229 with SMTP id wl5mr2588871obc.45.1407943939201; Wed, 13 Aug 2014 08:32:19 -0700 (PDT) X-Received: by 10.50.138.69 with SMTP id qo5mr875371igb.7.1407943939106; Wed, 13 Aug 2014 08:32:19 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!h18no12603392igc.0!news-out.google.com!px9ni588igc.0!nntp.google.com!h18no19596746igc.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 13 Aug 2014 08:32:18 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=66.126.103.122; posting-account=KSa2aQoAAACOxnC0usBJYX8NE3x3a1Xq NNTP-Posting-Host: 66.126.103.122 References: <892c6798-489d-400a-bb9a-7a14605c493f@googlegroups.com> <58a951df-217b-48ee-bd0b-f9953f5b622b@googlegroups.com> <53eaea2e$0$32377$862e30e2@ngroups.net> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Pointer to instance of indefinite array? From: Adam Beneschan Injection-Date: Wed, 13 Aug 2014 15:32:19 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:21719 Date: 2014-08-13T08:32:18-07:00 List-Id: On Wednesday, August 13, 2014 12:47:40 AM UTC-7, Georg Bauhaus wrote: > Since 'Unrestricted_Access is not Ada but a GNAT specific pragma,=20 > and since it is not strictly needed, I think that standard Ada's own=20 > 'Unchecked_Acceess should be enough?=20 No, because of a somewhat obscure rule that deals with 'Access on an array = when the target type is access-to-unconstrained-array. The rule is in 3.10= .2(27-27.2). The reason for the rule is that access-to-unconstrained-array= types need to either carry or point to information about the bounds; and i= n implementations where the bounds have to be stored together with the data= , and the access object points to the bounds, you don't want to force the p= rogram to store the bounds for *every* array. Because of this, even if 'Unrestricted_Access compiles on GNAT in Per's exa= mple code, it would have to be tested to make sure it works. If there's no= bound information, then the resulting code will be incorrect. I think GNA= T stores the bounds next to the data, but I'm not sure.=20 > I remember something about the ICC compiler supporting an implementation > specific attribute similar to 'Unrestricted_Access. Is there a significan= t > advantage in using 'Unrestricted_Access in user programs, perhaps suppres= sion > of more checks so that to something runs a lot faster? 'Unrestricted_Access in ICC Ada just allows you to get the 'Access of somet= hing that wouldn't otherwise be legal. I think it's the same in GNAT, but = I'm not positive. Note that 'Unchecked_Access suppresses accessibility che= cks (allowing an access object to point to something on the stack that coul= d disappear before the access object does), and therefore it allows you to = violate the static accessibility rules, but it doesn't allow you to violate= other rules. For example, if you use X'Unchecked_Access, X still has to b= e aliased, and there are other rules that are still checked. 'Unrestricted= _Access suppresses checks like that too. (In addition (as Egil posted), it= can be used on subprograms, for which Ada doesn't allow 'Unchecked_Access.= ) So, no, 'Unrestricted_Access doesn't affect performance. In any case, the = only checks performed at run-time are accessibility-level checks, and 'Unch= ecked_Access suppresses those, so it's hard to come up with any further per= formance improvements. -- Adam