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: a07f3367d7,344faf475a6f812a X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.224.10.6 with SMTP id n6mr23740465qan.4.1366903192843; Thu, 25 Apr 2013 08:19:52 -0700 (PDT) X-Received: by 10.50.67.111 with SMTP id m15mr1810942igt.12.1366903192614; Thu, 25 Apr 2013 08:19:52 -0700 (PDT) Path: ef9ni16888qab.0!nntp.google.com!gp5no6821780qab.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 25 Apr 2013 08:19:52 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ NNTP-Posting-Host: 66.126.103.122 References: <97967083-d21d-4de2-aeb8-76d0d5818993@googlegroups.com> <03e84773-d616-4a46-8189-93ae4ab5fcbf@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <311a34d1-5527-4abc-9677-be3b2c8d3739@googlegroups.com> Subject: Re: Interresting difference in Normal-Returns/Expression-Functions and Extended-Returns. From: Adam Beneschan Injection-Date: Thu, 25 Apr 2013 15:19:52 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2013-04-25T08:19:52-07:00 List-Id: On Thursday, April 25, 2013 1:48:47 AM UTC-7, egilhh wrote: > > I don't see a language reason for that. The tasks are all created with= allocators, and the type of the allocator alone should determine what mast= er the tasks depend on--not a block declaring an array that contains the ac= cess objects. If it's true that the block doesn't exit until all the tasks= created by allocators have completed, then it's probably a GNAT bug. I'd = need to study it more carefully to make sure, though. There may be some re= levant language rules I'm missing, or something else I'm missing. > I've been reading up on the accessibility rules (RM 3.10.2), and the rule= s > for functions returning anonymous access types have changed from 2005 to = 2012. > In my understanding, 2012 now requires the block to wait: >=20 > RM 3.10.2(10.1/3): "The accessibility level of the result of a function c= all is > that of the master of the function call, which is determined by the point= of > call as follows:" >=20 > RM 3.10.2(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 (s= ee > below) that becomes a coextension of another object, the master is that o= f the > eventual object to which the coextension will be transferred." >=20 > RM 3.10.2(10.7/3): "In the case of a call to a function whose result type > is an anonymous access type, the accessibility level of the type of the r= esult > of the function call is also determined by the point of call as described > above"), >=20 > whereas 2005 permitted the other behavior. (A language lawyer is needed t= o > confirm this) Offhand, I don't think these new rules are relevant to this particular ques= tion. They define the "master of a function call". However, the master on= which a task created by an allocator depends is the "master that includes = the elaboration of the declaration of the ultimate ancestor of the given ac= cess type" (9.3(2)), which I think is different. Basically, I think that i= f the new rules in 3.10.2 were supposed to impact how a master is computed = for an allocator that returns anonymous-access-to-task, something would hav= e to be changed in 9.3(2) as well. Also, I think that the new changes were= supposed to change how accessibility levels are determined (for the purpos= es of doing accessibility checks and preventing dangling references), not t= o change what tasks depend on. But I could be wrong, and it's certainly po= ssible that this was a combination of features that escaped the notice of t= he language designers when this change was made. Thanks for finding the new rules; I wasn't really aware of them (I was awar= e that there were some changes but I didn't know much about what they were)= . I really am not sure my analysis is correct. Probably, a language lawye= r who was involved in AI05-234 needs to weigh in. I'll probably try to rea= d that AI also to see if accesses-to-tasks and/or task dependence were disc= ussed at all, and what was said about them. The whole thing is pretty conf= using. -- Adam