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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Received: by 2002:a6b:1702:: with SMTP id 2-v6mr15141996iox.101.1525642083270; Sun, 06 May 2018 14:28:03 -0700 (PDT) X-Received: by 2002:a9d:24a1:: with SMTP id z30-v6mr545462ota.4.1525642083083; Sun, 06 May 2018 14:28:03 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.uzoreto.com!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!u74-v6no2144811itb.0!news-out.google.com!b185-v6ni4483itb.0!nntp.google.com!u74-v6no2144806itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sun, 6 May 2018 14:28:02 -0700 (PDT) In-Reply-To: <31262263-1919-451d-bacd-663494df19fa@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=68.147.43.80; posting-account=lzqe5AoAAADHhp_gregSufVhvwu22fBS NNTP-Posting-Host: 68.147.43.80 References: <9839db28-b6c6-44c9-9d36-336a39c12f25@googlegroups.com> <9a41b8a3-2ac9-4630-8028-2ba165b0fb0b@googlegroups.com> <5eec9be4-03ab-4cbc-8de5-0e9697228ab6@googlegroups.com> <31262263-1919-451d-bacd-663494df19fa@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <6e66aa5f-9ce0-4f28-ae1b-9bdfeb500a79@googlegroups.com> Subject: Re: Recommendation of safe subset of Ada to use? From: Brad Moore Injection-Date: Sun, 06 May 2018 21:28:03 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:52052 Date: 2018-05-06T14:28:02-07:00 List-Id: On Sunday, May 6, 2018 at 7:48:02 AM UTC-6, Jere wrote: > On Sunday, May 6, 2018 at 9:15:42 AM UTC-4, Jere wrote: > > On Sunday, May 6, 2018 at 3:43:11 AM UTC-4, Jeffrey R. Carter wrote: > > > On 05/05/2018 11:32 PM, gorgelo wrote: > > > >> with Ada.Text_IO; use Ada.Text_IO; > > > >> > > > >> procedure jdoodle is > > > >> type Integer_Access is access all Integer; > > > >> =20 > > > >> function Inner(Value : aliased in out Integer) return Intege= r_Access is > > > >> begin > > > >> return Value'Access; > > > >> end Inner; > > > >> =20 > > > >> function Outer return Integer_Access is > > > >> Value : aliased Integer :=3D 0; > > > >> begin > > > >> return Inner(Value); > > > >> end Outer; > > > >> =20 > > > >> Ptr : Integer_Access :=3D Outer; -- !!! Dangling reference > > > >> begin > > > >> Put_Line("Hello World"); > > > >> end jdoodle; > > >=20 > > > This seems to violate ARM 3.10.2(29): the accessibility level of Valu= e (the=20 > > > object passed by reference to Inner) is deeper than that of the acces= s type=20 > > > Integer_Access. I cannot find an exception to this for aliased parame= ters. > > >=20 > > > --=20 > > > Jeff Carter > > > "It is the German who is so uncourteous to his verbs." > > > A Scandal in Bohemia > > > 122 > >=20 > > How would you interpret 3.10.2 (7/4)? It just says it doesn't have the= same > > accessibility level as the master. I haven't found anything to suggest > > what the accessibility level should be at that point. I'll admit, I=20 > > haven't grasped what the full meaning is. >=20 > Trying to piece this together from the RM: >=20 > 6.4.1 (6.4/3): > In a function call, the accessibility level of the actual object for each= =20 > explicitly aliased parameter shall not be statically deeper than the=20 > accessibility level of the master of the call (see 3.10.2). >=20 > The only reference to how the accessibility level of the master was=20 > determined that I could fine was in=20 > 6.10.2 (10.1/3): > 10.1/3 > The accessibility level of the result of a function call is that of the m= aster=20 > of the function call, which is determined by the point of call as follows= : > 10.2/3 > If the result is used (in its entirety) to directly initialize part of an= object,=20 > the master is that of the object being initialized. In the case where the= initialized=20 > object is a coextension (see below) that becomes a coextension of another= object,=20 > the master is that of the eventual object to which the coextension will b= e transferred. > 10.3/3 > If the result is of an anonymous access type and is the operand of an exp= licit=20 > conversion, the master is that of the target type of the conversion; > 10.4/3 > If the result is of an anonymous access type and defines an access discri= minant,=20 > the master is the same as that for an object created by an anonymous allo= cator=20 > that defines an access discriminant (even if the access result is of an= =20 > access-to-subprogram type). > 10.5/3 > If the call itself defines the result of a function to which one of the a= bove=20 > rules applies, these rules are applied recursively; > 10.6/3 > In other cases, the master of the call is that of the innermost master th= at=20 > evaluates the function call. >=20 > I know this is meant to define the level for the result, but it also is t= he > only part that I could find that defines the level of the master of the c= all. > Here it would seem that 10.6/3 would apply? >=20 > Reading the RM is rough! Any help out there? It's rough where you are looking. But I think you should be looking more at= 3.10.2, as that is where the accessibility rules are defined, and its not = going to get any less rough over there either.=20 But before you do that, you might want to read this quote from the AARM.=20 See 3.10.2 (3.b/3) Subclause 3.10.2, home of the accessibility rules, is informally known as t= he =E2=80=9CHeart of Darkness=E2=80=9D amongst the maintainers of Ada. Woe = unto all who enter here (well, at least unto anyone that needs to understan= d any of these rules)."=20 This is because, probably only a very small handful of people on this plane= t actually truly understand the rules. I am not one of those, though I try = my best, when I need to. And those that do, it is only for a fleeting momen= t. It typically requires a deep dive into the Heart of Darkness. If you rea= ch enlightenment, consider yourself lucky. Randy would be one of the lucky = people, but even he will avoid diving into the Heart of Darkness if he does= n't need to :-) =20 I think one of the main advantages of the aliased keyword on subprogram par= ameters, is that it means there is much less need to use access types. You can now, for the most part, keep access types hidden in the private par= t or body of a package, and not expose access types in the public part of t= he package specification. Users of a package do not have to deal with acces= s types, when this design convention is in place. I think it is a good desi= gn principle to strive to not expose access types in the public part of a p= ackage. With earlier versions of Ada, it was much harder to avoid doing this. That is largely the case with the containers. The users of the container pa= ckages normally shouldn't need to mess with access types.=20 Also, offhand, I think the problem originally posted above is a compiler bu= g, that should be fixed.=20 Brad