* have to use unrestricted access but just what about access @ 2002-06-19 23:32 chris.danx 2002-06-20 8:41 ` chris.danx ` (3 more replies) 0 siblings, 4 replies; 13+ messages in thread From: chris.danx @ 2002-06-19 23:32 UTC (permalink / raw) Hi, How can the unrestricted_access attribute be replaced by just access in the following code? procedure on_create (window : in out dot_window) is begin ... -- watcher is a task which uses key_coordinator -- (a protected object) to record certain keypresses -- which another task retrieves and does it's thing -- with. -- Window.Watcher := new Dot_Key_Watcher.Watcher (Window.Key_Coordinator'Unrestricted_Access); ... end on_create; -- this is the window where watcher and key_coordinator live. -- type Dot_Window is new Gwindows.Windows.Main.Main_Window_Type with record Drawing_Surface : Gwindows.Drawing_Panels.Drawing_Panel_Type; Key_Coordinator : aliased Dot_Key_Coor.Coordinator; Watcher : Dot_Key_Watcher.Watcher_Access; Builder : Dot_Builder.Builder_Access; end record; I understand what is meant by "non-local pointer cannot point to local object" in the case of 'access I just can't think of a way to fix it. It's really just curiosity, (the code is limited to GNAT anyway!) it'd just be nice to find out a more general solution since this problem could arise elsewhere. Chris ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: have to use unrestricted access but just what about access 2002-06-19 23:32 have to use unrestricted access but just what about access chris.danx @ 2002-06-20 8:41 ` chris.danx 2002-06-20 12:10 ` SteveD ` (2 subsequent siblings) 3 siblings, 0 replies; 13+ messages in thread From: chris.danx @ 2002-06-20 8:41 UTC (permalink / raw) "chris.danx" <spamoff.danx@ntlworld.com> wrote in message news:0x8Q8.6779$ZP1.1263481@news11-gui.server.ntli.net... > Hi, > > How can the unrestricted_access attribute be replaced by just access in the > following code? It's simple, just change key_coordinator to an access type and dynamically allocate it, then remove 'unrestricted_access from the on_create procedure. Don't know why I didn't see it before! Chris ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: have to use unrestricted access but just what about access 2002-06-19 23:32 have to use unrestricted access but just what about access chris.danx 2002-06-20 8:41 ` chris.danx @ 2002-06-20 12:10 ` SteveD 2002-06-20 14:22 ` Robert A Duff 2002-06-20 16:05 ` Robert Dewar 3 siblings, 0 replies; 13+ messages in thread From: SteveD @ 2002-06-20 12:10 UTC (permalink / raw) "chris.danx" <spamoff.danx@ntlworld.com> wrote in message news:0x8Q8.6779$ZP1.1263481@news11-gui.server.ntli.net... > Hi, > > How can the unrestricted_access attribute be replaced by just access in the > following code? > You didn't provide enough code in your example to answer the question. Namely where your structure is defined. If it is defined inside a procedure you'll need Unchecked_Access (although Unrestricted_Access will work). SteveD ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: have to use unrestricted access but just what about access 2002-06-19 23:32 have to use unrestricted access but just what about access chris.danx 2002-06-20 8:41 ` chris.danx 2002-06-20 12:10 ` SteveD @ 2002-06-20 14:22 ` Robert A Duff 2002-06-21 11:45 ` Robert Dewar 2002-06-20 16:05 ` Robert Dewar 3 siblings, 1 reply; 13+ messages in thread From: Robert A Duff @ 2002-06-20 14:22 UTC (permalink / raw) "chris.danx" <spamoff.danx@ntlworld.com> writes: > How can the unrestricted_access attribute be replaced by just access in the > following code? You should be using 'Unchecked_Access here, which is a standard feature of Ada (albeit unsafe). 'Unrestricted_Access is a feature of GNAT, and is not necessary in your example. - Bob ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: have to use unrestricted access but just what about access 2002-06-20 14:22 ` Robert A Duff @ 2002-06-21 11:45 ` Robert Dewar 2002-06-22 0:49 ` Robert A Duff 2002-07-20 4:59 ` Craig Carey 0 siblings, 2 replies; 13+ messages in thread From: Robert Dewar @ 2002-06-21 11:45 UTC (permalink / raw) Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message news:<wccznxqni7o.fsf@shell01.TheWorld.com>... > "chris.danx" <spamoff.danx@ntlworld.com> writes: > > > How can the unrestricted_access attribute be replaced by just access in the > > following code? > > You should be using 'Unchecked_Access here, which is a standard feature > of Ada (albeit unsafe). > > 'Unrestricted_Access is a feature of GNAT, and is not necessary in your > example. > > - Bob Bob look again! One of the nasty restrictions in Ada 95 is that you cannot make parameters aliased. This means that they can never be used in access attributes. This is indeed one use of unrestricted access that is useful and legitimate, though of course passing such an access value out assumes call by reference, and you have to be sure that you can gaurantee call by reference. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: have to use unrestricted access but just what about access 2002-06-21 11:45 ` Robert Dewar @ 2002-06-22 0:49 ` Robert A Duff 2002-06-22 1:05 ` Ted Dennison 2002-07-20 4:59 ` Craig Carey 1 sibling, 1 reply; 13+ messages in thread From: Robert A Duff @ 2002-06-22 0:49 UTC (permalink / raw) dewar@gnat.com (Robert Dewar) writes: > Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message news:<wccznxqni7o.fsf@shell01.TheWorld.com>... > > "chris.danx" <spamoff.danx@ntlworld.com> writes: > > > > > How can the unrestricted_access attribute be replaced by just access in the > > > following code? > > > > You should be using 'Unchecked_Access here, which is a standard feature > > of Ada (albeit unsafe). > > > > 'Unrestricted_Access is a feature of GNAT, and is not necessary in your > > example. > > > > - Bob > > Bob look again! > One of the nasty restrictions in Ada 95 is that you cannot make parameters > aliased. This means that they can never be used in access attributes. This > is indeed one use of unrestricted access that is useful and legitimate, though > of course passing such an access value out assumes call by reference, and you > have to be sure that you can gaurantee call by reference. Oh. I thought we were talking about a *component* of a parameter, where the component was explicitly declared aliased. Also, you can make a parameter aliased by making it tagged. I agree that this is a nasty restriction in Ada 95 -- one ought to be allowed to declare the parameter aliased explicitly, and taggedness shouldn't have anything to do with the matter. - Bob ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: have to use unrestricted access but just what about access 2002-06-22 0:49 ` Robert A Duff @ 2002-06-22 1:05 ` Ted Dennison 2002-06-22 12:09 ` Robert Dewar 0 siblings, 1 reply; 13+ messages in thread From: Ted Dennison @ 2002-06-22 1:05 UTC (permalink / raw) Robert A Duff wrote: > I agree that this is a nasty restriction in Ada 95 -- one ought to be > allowed to declare the parameter aliased explicitly, and taggedness > shouldn't have anything to do with the matter. Isn't that what the "access" parameter mode does? Sure, you have to announce your intentions in the subprogram's interface, but that is arguably a good thing too. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: have to use unrestricted access but just what about access 2002-06-22 1:05 ` Ted Dennison @ 2002-06-22 12:09 ` Robert Dewar 0 siblings, 0 replies; 13+ messages in thread From: Robert Dewar @ 2002-06-22 12:09 UTC (permalink / raw) Ted Dennison <dennison@telepath.com> wrote in message news:<3D13CD23.9080404@telepath.com>... > Robert A Duff wrote: > > I agree that this is a nasty restriction in Ada 95 -- one ought to be > > allowed to declare the parameter aliased explicitly, and taggedness > > shouldn't have anything to do with the matter. > > Isn't that what the "access" parameter mode does? Sure, you have to > announce your intentions in the subprogram's interface, but that is > arguably a good thing too. No, you miss the point. Suppose you have a function with a parameter X : integer. Now you want to call another function that expects an access type (perhaps an external C function). You want to be able to pass X'Unchecked_Access to that inner function, but you can't, because you can't make X aliased. I often want to create temp access values referencing parameters, it's a perfectly reasonable requirement, and one that is handled in GNAT by using unrestricted access. of course, just as when you use 'Address, you have to be careful (remember that for objects, Unrestricted_Access in GNAT is nothing more than 'Address and an unchecked conversion to the appropriate pointer type). The advantage of Unrestricted_Access in GNAT is that it encourages using typed interfaces instead of degenerating to using System.Address. It is no more dangerous than 'Address, but just because you are going down to the semantic level of dealing with low level addresses or pointers does not mean you have to give up typing (after all pointers in C are strongly typed, so it is a shame that in a lot of Ada 83 code you get interfaces to C functions where on the Ada side you give up on typing by using 'Address when the C side is strongly typed :-) ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: have to use unrestricted access but just what about access 2002-06-21 11:45 ` Robert Dewar 2002-06-22 0:49 ` Robert A Duff @ 2002-07-20 4:59 ` Craig Carey 2002-07-20 17:47 ` Robert A Duff 1 sibling, 1 reply; 13+ messages in thread From: Craig Carey @ 2002-07-20 4:59 UTC (permalink / raw) On 21 Jun 2002 04:45:08 -0700, dewar@gnat.com (Robert Dewar) wrote: >Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message news:<wccznxqni7o.fsf@shell01.TheWorld.com>... >> "chris.danx" <spamoff.danx@ntlworld.com> writes: >> >> > How can the unrestricted_access attribute be replaced by just access in the >> > following code? >> >> You should be using 'Unchecked_Access here, which is a standard feature >> of Ada (albeit unsafe). >> >> 'Unrestricted_Access is a feature of GNAT, and is not necessary in your >> example. >> >> - Bob > >Bob look again! > >One of the nasty restrictions in Ada 95 is that you cannot make parameters >aliased. This means that they can never be used in access attributes. This >is indeed one use of unrestricted access that is useful and legitimate, though >of course passing such an access value out assumes call by reference, and you >have to be sure that you can gaurantee call by reference. Isn't having a parameter mode by "by-reference" about the same as having it aliased. A type can be made to be by-reference using "pragma Voltile". (That statement can be put inside of the record that points into itself, and affect the record type and the type that is a pointer to that record). AARM 6.2 "Formal Parameter Modes", 10.e says: C.6, ``Shared Variable Control'' says that a composite type with an atomic or volatile subcomponent is a by-reference type, among other things. AARM & RM C.6 Shared Variable Control, 18 says: If a type is atomic or volatile and it is not a by-copy type, then the type is defined to be a by-reference type. If any subcomponent of a type is atomic or volatile, then the type is defined to be a by-reference type. If a field were made Volatile then the whole record ought be passed by reference, i.e. be aliased, according to AARM's C.6. Here is some code that compiles on ObjectAda and GNAT: ----------------------------------------------------------- package Ptr_Into_Rec is type Main_Window_Type is tagged limited null record; type Coordinator is null record; type Watcher_Access is access all Coordinator; type Ensure_By_Reference is private; pragma Volatile (Coordinator); pragma Volatile (Watcher_Access); type Dot_Window is new Main_Window_Type with record Key_Coordinator : aliased Coordinator; Watcher : Watcher_Access; Dont_Use : Ensure_By_Reference; end record; procedure Update (X : in out Dot_Window); private type Ensure_By_Reference is mod 2; pragma Volatile (Ensure_By_Reference); pragma Volatile (Dot_Window); end Ptr_Into_Rec; package body Ptr_Into_Rec is procedure Update (X : in out Dot_Window) is begin X.Watcher := X.Key_Coordinator'Unchecked_Access; end Update; end Ptr_Into_Rec; ----------------------------------------------------------- My experimental StriUnli strings package (a replacement for Unbounded Strings that allows pointer swapping) uses a record that points back into itself. StriUnli: http://www.ijs.co.nz/code/ada95_strings_http_hdrs.zip It doesn't seem to be unsafe. Craig Carey, http://www.ijs.co.nz/ada_95 (some Ada 95 mailing lists) ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: have to use unrestricted access but just what about access 2002-07-20 4:59 ` Craig Carey @ 2002-07-20 17:47 ` Robert A Duff 2002-07-21 8:45 ` Craig Carey 0 siblings, 1 reply; 13+ messages in thread From: Robert A Duff @ 2002-07-20 17:47 UTC (permalink / raw) Craig Carey <research@ada95.ijs.com> writes: > Isn't having a parameter mode by "by-reference" about the same as having > it aliased. No. If you look up the definition of "aliased", I don't think you'll find any mention of "by reference". If a parameter is aliased, then it had better be passed by reference. But that's a rule for the language designer to obey, not the programmer. For example, in Ada tagged parameters are aliased, and they are passed by reference. But the other way around is not true: passing a parameter by reference does not imply that it's aliased. >... A type can be made to be by-reference using "pragma Voltile". But you wouldn't want to do that, because it might damage efficiency. To make a type be by-reference, make it a limited record. If it's scalar, wrap it inside a limited record. To make a parameter aliased, make it's type tagged. (Yuck; I don't like that rule.) > (That statement can be put inside of the record that points into itself, > and affect the record type and the type that is a pointer to that > record). > > AARM 6.2 "Formal Parameter Modes", 10.e says: > C.6, ``Shared Variable Control'' says that a composite type with an > atomic or volatile subcomponent is a by-reference type, among other > things. > > AARM & RM C.6 Shared Variable Control, 18 says: > If a type is atomic or volatile and it is not a by-copy type, then > the type is defined to be a by-reference type. If any subcomponent > of a type is atomic or volatile, then the type is defined to be a > by-reference type. > > If a field were made Volatile then the whole record ought be > passed by reference, i.e. be aliased, according to AARM's C.6. > > Here is some code that compiles on ObjectAda and GNAT: In the code below, Dot_Window is tagged, and therefore is a pass-by-ref type. No need for the Volatile business (unless you wanted volatile for other reasons). I'm not sure why you put Volatile on Watcher_Access, but in any case, it is a by-copy type (even with the Volatile). Note the "and it is not a by-copy type" wording in C.6. > ----------------------------------------------------------- > package Ptr_Into_Rec is > > type Main_Window_Type is tagged limited null record; > > type Coordinator is null record; > type Watcher_Access is access all Coordinator; > type Ensure_By_Reference is private; > > pragma Volatile (Coordinator); > pragma Volatile (Watcher_Access); > > type Dot_Window is new Main_Window_Type > with record > Key_Coordinator : aliased Coordinator; > Watcher : Watcher_Access; > Dont_Use : Ensure_By_Reference; > end record; > > procedure Update (X : in out Dot_Window); > > private > type Ensure_By_Reference is mod 2; > pragma Volatile (Ensure_By_Reference); > pragma Volatile (Dot_Window); > end Ptr_Into_Rec; > > > package body Ptr_Into_Rec is > > procedure Update (X : in out Dot_Window) is > begin > X.Watcher := X.Key_Coordinator'Unchecked_Access; > end Update; > > end Ptr_Into_Rec; > > ----------------------------------------------------------- > > My experimental StriUnli strings package (a replacement for Unbounded > Strings that allows pointer swapping) uses a record that points back > into itself. StriUnli: > http://www.ijs.co.nz/code/ada95_strings_http_hdrs.zip > > > It doesn't seem to be unsafe. > > > Craig Carey, > > http://www.ijs.co.nz/ada_95 (some Ada 95 mailing lists) ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: have to use unrestricted access but just what about access 2002-07-20 17:47 ` Robert A Duff @ 2002-07-21 8:45 ` Craig Carey 0 siblings, 0 replies; 13+ messages in thread From: Craig Carey @ 2002-07-21 8:45 UTC (permalink / raw) On Sat, 20 Jul 2002 17:47:07 GMT, Robert A Duff <bobduff@shell01.TheWorld.com> wrote: ... >No. If you look up the definition of "aliased", I don't think you'll >find any mention of "by reference". ... >But the other way around is not true: passing a parameter by reference >does not imply that it's aliased. > Here is text from the AARM saying that internal formal parameter is an aliased view of the external actual object if the type is tagged. --------------- >AARM 3.10 Access Types ... >9 {aliased} ... In addition, the dereference of an access-to- >object value denotes an aliased view, as does a view conversion >(see 4.6) of an aliased view. Finally, the current instance of a >limited type, and a formal parameter or generic formal object of >a tagged type are defined to be aliased. [Aliased views are the >ones that can be designated by an access value.] ... ... >9.g A formal parameter of a tagged type is defined to be >aliased so that a (tagged) parameter X may be passed to an access >parameter P by using P => X'Access. Access parameters are most >important for tagged types because of dispatching-on-access- >parameters (see 3.9.2). By restricting this to formal parameters, >we minimize problems associated with allowing components that are >not declared aliased to be pointed-to from within the same >record. http://www.adaic.org/standards/95aarm/html/AA-3-10.html --------------- I am not clear on this here: if there is a java-like background garbage collector, then applying 'Access on a not-aliased but by-reference not-tagged and not limited but Volatile internal formal record object might sometimes fail to give the address of external actual object that is safe to use...?. (Section C.6 of the AARM does not contain the word "aliased"). Anyway, when the type is "tagged", 3.10(9) that the parameter passing is by the aliased mode (the actual external isn't cached or shifting, etc.). >>... A type can be made to be by-reference using "pragma Voltile". > >But you wouldn't want to do that, because it might damage efficiency. > My "pragma Volatile"s in the example can be deleted: the record was tagged. Thanks. >> Craig Carey, >> >> http://www.ijs.co.nz/ada_95 (some Ada 95 mailing lists) ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: have to use unrestricted access but just what about access 2002-06-19 23:32 have to use unrestricted access but just what about access chris.danx ` (2 preceding siblings ...) 2002-06-20 14:22 ` Robert A Duff @ 2002-06-20 16:05 ` Robert Dewar 2002-06-20 17:11 ` chris.danx 3 siblings, 1 reply; 13+ messages in thread From: Robert Dewar @ 2002-06-20 16:05 UTC (permalink / raw) "chris.danx" <spamoff.danx@ntlworld.com> wrote in message news:<0x8Q8.6779$ZP1.1263481@news11-gui.server.ntli.net>... > Hi, > > How can the unrestricted_access attribute be replaced by > just access in the following code? The referenced post in this thread is an excellent lesson in when how to seriously misuse the Unrestricted_Access attribute. Of course it is no worse than Address, since it is exactly equivalent to taking 'Address and then applying an unchecked conversion to get the access type in question. But even a cursory examination of this code will show that it is very likely to generate a dangling pointer. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: have to use unrestricted access but just what about access 2002-06-20 16:05 ` Robert Dewar @ 2002-06-20 17:11 ` chris.danx 0 siblings, 0 replies; 13+ messages in thread From: chris.danx @ 2002-06-20 17:11 UTC (permalink / raw) "Robert Dewar" <dewar@gnat.com> wrote in message news:5ee5b646.0206200805.7c4be786@posting.google.com... > The referenced post in this thread is an excellent lesson > in when how to seriously misuse the Unrestricted_Access > attribute. I wasn't comfortable with Unrestriced_Access anyway, so the code was changed it earlier today not to use Unrestricted_Access... type Dot_Window is new Gwindows.Windows.Main.Main_Window_Type with record Drawing_Surface : Gwindows.Drawing_Panels.Drawing_Panel_Access := null; Key_Coordinator : Dot_Key_Coor.Coordinator_Access := null; Watcher : Dot_Key_Watcher.Watcher_Access := null; Builder : Dot_Builder.Builder_Access := null; end record; Everything is dynamically allocated and if at any point an allocation fails, the program is terminated (after tidying up of course)! If you have a suggestion as to how to improve the mechanism by which the two tasks communicate I'd gladly listen. > But even a cursory examination of this code will show > that it is very likely to generate a dangling pointer. The tasks which use the protected object are terminated (and deallocated) before the protected object itself, so there should be no dangling pointer. I always make a point of noting where anything is allocated and under what circumstances they should be deallocated. ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2002-07-21 8:45 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-06-19 23:32 have to use unrestricted access but just what about access chris.danx 2002-06-20 8:41 ` chris.danx 2002-06-20 12:10 ` SteveD 2002-06-20 14:22 ` Robert A Duff 2002-06-21 11:45 ` Robert Dewar 2002-06-22 0:49 ` Robert A Duff 2002-06-22 1:05 ` Ted Dennison 2002-06-22 12:09 ` Robert Dewar 2002-07-20 4:59 ` Craig Carey 2002-07-20 17:47 ` Robert A Duff 2002-07-21 8:45 ` Craig Carey 2002-06-20 16:05 ` Robert Dewar 2002-06-20 17:11 ` chris.danx
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox