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: adam@irvine.com Subject: Re: Subverting 'Access for Sub-programs Date: 1999/08/05 Message-ID: <7occq3$g9v$1@nnrp1.deja.com>#1/1 X-Deja-AN: 509207298 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 x39.deja.com:80 (Squid/1.1.22) for client 204.17.204.34 Organization: Deja.com - Share what you know. Learn what you don't. X-Article-Creation-Date: Thu Aug 05 16:06:37 1999 GMT X-MyDeja-Info: XMYDJUIDabeneschan Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.6 [en] (X11; I; Linux 2.2.5-22 i686) Date: 1999-08-05T00:00:00+00:00 List-Id: In article <7oc5ih$6mb$1@wanadoo.fr>, "Jean-Pierre Rosen" wrote: > > OK, I understand your problem better (full examples always help :-) > Of course, you realize that "Integrator" could store the pointer to > function to any global variable, possibly resulting later in random > branches. I think the trade-off in language design was that accessing > random memory location was bad, but not THAT bad. OTOH, branching to > random locations was considered really too dangerous. Even if you > promise not to store the pointer to function to anything global, it > would be a property of the body, i.e. something that could be changed > without anybody noticing . . . Couldn't it be made a property of the access type, instead of a property of the body? Was any solution like this considered, when Ada 95 was designed? The inability to take an 'ACCESS of an inner subprogram seems like an obnoxious restriction, a step down from Pascal and Algol, and it seems like programmers should have an option to remove this restriction at the expense of adding restrictions elsewhere or perhaps adding runtime checks. In fact, I kind of like the idea of allowing a different kind of subprogram access type declaration such that 3.10.2(28) wouldn't apply to that type, where the program must check to make sure the subprogram's ancestors are still on the stack when objects of the type get dereferenced. I suspect that in the Integrate case, the compiler would even be able to tell that this runtime check is unnecessary. Comments? -- Adam Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't.