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:ce9:: with SMTP id 102-v6mr19485431iom.134.1525614480668; Sun, 06 May 2018 06:48:00 -0700 (PDT) X-Received: by 2002:a9d:73c9:: with SMTP id m9-v6mr2398914otk.9.1525614480213; Sun, 06 May 2018 06:48:00 -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-v6no1890495itb.0!news-out.google.com!b185-v6ni4093itb.0!nntp.google.com!u74-v6no1890493itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sun, 6 May 2018 06:47:59 -0700 (PDT) In-Reply-To: <5eec9be4-03ab-4cbc-8de5-0e9697228ab6@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=96.247.198.106; posting-account=QF6XPQoAAABce2NyPxxDAaKdAkN6RgAf NNTP-Posting-Host: 96.247.198.106 References: <9839db28-b6c6-44c9-9d36-336a39c12f25@googlegroups.com> <9a41b8a3-2ac9-4630-8028-2ba165b0fb0b@googlegroups.com> <5eec9be4-03ab-4cbc-8de5-0e9697228ab6@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <31262263-1919-451d-bacd-663494df19fa@googlegroups.com> Subject: Re: Recommendation of safe subset of Ada to use? From: Jere Injection-Date: Sun, 06 May 2018 13:48:00 +0000 Content-Type: text/plain; charset="UTF-8" Xref: reader02.eternal-september.org comp.lang.ada:52038 Date: 2018-05-06T06:47:59-07:00 List-Id: 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; > > >> > > >> function Inner(Value : aliased in out Integer) return Integer_Access is > > >> begin > > >> return Value'Access; > > >> end Inner; > > >> > > >> function Outer return Integer_Access is > > >> Value : aliased Integer := 0; > > >> begin > > >> return Inner(Value); > > >> end Outer; > > >> > > >> Ptr : Integer_Access := Outer; -- !!! Dangling reference > > >> begin > > >> Put_Line("Hello World"); > > >> end jdoodle; > > > > This seems to violate ARM 3.10.2(29): the accessibility level of Value (the > > object passed by reference to Inner) is deeper than that of the access type > > Integer_Access. I cannot find an exception to this for aliased parameters. > > > > -- > > Jeff Carter > > "It is the German who is so uncourteous to his verbs." > > A Scandal in Bohemia > > 122 > > 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 > haven't grasped what the full meaning is. Trying to piece this together from the RM: 6.4.1 (6.4/3): In a function call, the accessibility level of the actual object for each explicitly aliased parameter shall not be statically deeper than the accessibility level of the master of the call (see 3.10.2). The only reference to how the accessibility level of the master was determined that I could fine was in 6.10.2 (10.1/3): 10.1/3 The accessibility level of the result of a function call is that of the master 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, the master is that of the object being initialized. In the case where the initialized object is a coextension (see below) that becomes a coextension of another object, the master is that of the eventual object to which the coextension will be transferred. 10.3/3 If the result is of an anonymous access type and is the operand of an explicit 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 discriminant, the master is the same as that for an object created by an anonymous allocator that defines an access discriminant (even if the access result is of an access-to-subprogram type). 10.5/3 If the call itself defines the result of a function to which one of the above rules applies, these rules are applied recursively; 10.6/3 In other cases, the master of the call is that of the innermost master that evaluates the function call. I know this is meant to define the level for the result, but it also is the only part that I could find that defines the level of the master of the call. Here it would seem that 10.6/3 would apply? Reading the RM is rough! Any help out there?