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.3 required=5.0 tests=BAYES_00,INVALID_MSGID, MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,2308afbbe4ecec0b X-Google-Attributes: gid103376,public From: Robert Dewar Subject: Re: Subverting 'Access for Sub-programs Date: 1999/08/06 Message-ID: <7oejga$28i$1@nnrp1.deja.com>#1/1 X-Deja-AN: 509550283 References: <37A71EF1.2201@dera.gov.uk> <37A7FDE8.4F5@dera.gov.uk> <7o9vrv$qgt$1@wanadoo.fr> <7oc5ih$6mb$1@wanadoo.fr> X-Http-Proxy: 1.0 x24.deja.com:80 (Squid/1.1.22) for client 205.232.38.14 Organization: Deja.com - Share what you know. Learn what you don't. X-Article-Creation-Date: Fri Aug 06 12:13:05 1999 GMT X-MyDeja-Info: XMYDJUIDrobert_dewar Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.04 [en] (OS/2; I) Date: 1999-08-06T00:00:00+00:00 List-Id: In article , > It was probably the right choice at the time (1990-1995) to > exclude downward funargs, and Robert Dewar's statement about > the pain some implementor's would have suffered seems > reasonable enough. It won't seem reasonable much longer > though. Indeed! And probably it is time for the ARG to address this issue, and decide on an accepted language extension in this area. I am not sure that Unrestricted_Access (as defined by GNAT for procedures) should be part of that proposal. Most certainly you also want a "safe" version similar to what was proposed in earlier mapping documents (the limited access to subprogram feature). Note that Unrestricted_Access in GNAT has three quite different meanings: 1. For objects other than slices and unconstrained array types, it provides a considerably nicer diction than taking the 'Address and converting the address to the required access type by using unchecked conversion (a common Ada 83 diction). Since it adds no expressive capability, and is obviously no implementation burden, this usage seems one that would usefully be included in all Ada compilers. 2. For slice objects and unconstrained array type pointers, GNAT permits capturing pointers to slices that "work", although there are fairly subtle scoping restrictions. This very much depends on the internal approach that GNAT uses for such pointers (the so called "fat" pointers). It is not a usage that should be encouraged, and certainly not one that should be standardized at this time, since it would have far reaching implementation impact in compilers other than GNAT. So this use of Unrestricted_Access should definitely be considered to be GNAT dependent (it can of course be VERY useful in some situations, e.g. we have found it very useful for some work in automatic translation of COBOL code). 3. For subprograms, Unrestricted_Access provides a general mechanism corresponding really to what would more naturally be called Unchecked_Access, and to me the natural extension in the language would be to use Unchecked_Access for the purpose. I don't see any big semantic problem here. Pointers generated by the use of UA are the same as any other pointers generated by use of UA, namely you had better not use them when the corresponding referenced gizmo (be it an object as now allowed in the language, or a subprogram, as now forbidden) goes out of scope. The implementation impact is no worse than will be required for general downward funargs, so if you buy the latter, why not allow Unchecked_Access on subprograms as the natural extension. I think that even if you implement the "safe" downward funargs features, you will still feel a need for UA on subprograms. The situations in which you need this are exactly similar to those which cause you to use UA for objects, e.g. you want to park pointers in some global structures, for later use, and you happen to know that your logic is such that they will not be used after the referenced gizmo has gone out of scope. For example, I have a general library level procedure that does callbacks, and expects to be passed a record containing the stuff necessary for the callback processing, including an access-to-subprogram value. Currently I can't use a nested subprogram for that purpose which is annoying, and the "safe" proposal still won't allow it. Robert Dewar Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't.