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/05 Message-ID: <7ocrnv$sf2$1@nnrp1.deja.com>#1/1 X-Deja-AN: 509291027 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 x41.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: Thu Aug 05 20:21:33 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-05T00:00:00+00:00 List-Id: In article , Robert A Duff wrote: > The language ended up with call backs, but not downward > closures. Not inappropriate, because call backs were the new feature not considered in the design of Ada 83. The downward closure issue has not changed at all from the design of Ada 83, and in fact it was not clear there was a sufficiently good reason to embroider in this area. > Your comment is, of course, also true of what we ended up with > 'Unrestricted_Access, which is neither safe nor portable -- > it's even less checked than 'Unchecked_Access. Well that's a bit confused. There is no Unchecked_Access for subprograms, so I am not quite sure what the comparison would mean there ... For other than subprograms, Unrestricted_Access is equivalent to (though preferable to, since more checked) than taking 'Address followed by an unchecked conversion. It is to that construct that Unrestricted_Access should be compared, not Unchecked_Access. The fact of the matter is that even with the design teams proposals, there are still cases where Unrestricted_Access would be useful for subprograms, since there are cases which are safe, but the compiler cannot tell they are safe. To me the dangling data references of Unchecked_Access are not particularly better than the dangling subprogram pointers of Unrestricted_Access. The consequence of either is possible data corruption (in the former case, from a bad address, in the latter case from a bad static link). Note that Unrestricted_Access applied to an inner procedure with no non-local references is in fact entirely safe (such nested procedures are not at all uncommon, they are used in cases where you want to restrict the visibility of a local nested subprogram). Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't.