have to use unrestricted access but just what about access

have to use unrestricted access but just what about access

[chris.danx]

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

Re: have to use unrestricted access but just what about access

[chris.danx]

"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

Re: have to use unrestricted access but just what about access

[SteveD]

"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

Re: have to use unrestricted access but just what about access

[Robert A Duff]

"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

Re: have to use unrestricted access but just what about access

[Robert Dewar]

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.

Re: have to use unrestricted access but just what about access

[Robert A Duff]

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

Re: have to use unrestricted access but just what about access

[Ted Dennison]

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.

Re: have to use unrestricted access but just what about access

[Robert Dewar]

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 :-)

Re: have to use unrestricted access but just what about access

[Craig Carey]

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)

Re: have to use unrestricted access but just what about access

[Robert A Duff]

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)

Re: have to use unrestricted access but just what about access

[Craig Carey]

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)

Re: have to use unrestricted access but just what about access

[Robert Dewar]

"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.

Re: have to use unrestricted access but just what about access

[chris.danx]

"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.