4.72 Attribute Unrestricted_Access ¶

The Unrestricted_Access attribute is similar to Access except that all accessibility and aliased view checks are omitted. This is a user-beware attribute.

For objects, it is similar to Address, for which it is a desirable replacement where the value desired is an access type. In other words, its effect is similar to first applying the Address attribute and then doing an unchecked conversion to a desired access type.

For subprograms, P'Unrestricted_Access may be used where P'Access would be illegal, to construct a value of a less-nested named access type that designates a more-nested subprogram. This value may be used in indirect calls, so long as the more-nested subprogram still exists; once the subprogram containing it has returned, such calls are erroneous. For example:

package body P is

   type Less_Nested is not null access procedure;
   Global : Less_Nested;

   procedure P1 is
   begin
      Global.all;
   end P1;

   procedure P2 is
      Local_Var : Integer;

      procedure More_Nested is
      begin
         ... Local_Var ...
      end More_Nested;
   begin
      Global := More_Nested'Unrestricted_Access;
      P1;
   end P2;

end P;

When P1 is called from P2, the call via Global is OK, but if P1 were called after P2 returns, it would be an erroneous use of a dangling pointer.

For objects, it is possible to use Unrestricted_Access for any type. However, if the result is of an access-to-unconstrained array subtype, then the resulting pointer has the same scope as the context of the attribute, and must not be returned to some enclosing scope. For instance, if a function uses Unrestricted_Access to create an access-to-unconstrained-array and returns that value to the caller, the result will involve dangling pointers. In addition, it is only valid to create pointers to unconstrained arrays using this attribute if the pointer has the normal default ’fat’ representation where a pointer has two components, one points to the array and one points to the bounds. If a size clause is used to force ’thin’ representation for a pointer to unconstrained where there is only space for a single pointer, then the resulting pointer is not usable.

In the simple case where a direct use of Unrestricted_Access attempts to make a thin pointer for a non-aliased object, the compiler will reject the use as illegal, as shown in the following example:

with System; use System;
procedure SliceUA2 is
   type A is access all String;
   for A'Size use Standard'Address_Size;

   procedure P (Arg : A) is
   begin
      null;
   end P;

   X : String := "hello world!";
   X2 : aliased String := "hello world!";

   AV : A := X'Unrestricted_Access;    -- ERROR
             |
>>> illegal use of Unrestricted_Access attribute
>>> attempt to generate thin pointer to unaliased object

begin
   P (X'Unrestricted_Access);          -- ERROR
      |
>>> illegal use of Unrestricted_Access attribute
>>> attempt to generate thin pointer to unaliased object

   P (X(7 .. 12)'Unrestricted_Access); -- ERROR
      |
>>> illegal use of Unrestricted_Access attribute
>>> attempt to generate thin pointer to unaliased object

   P (X2'Unrestricted_Access);         -- OK
end;

but other cases cannot be detected by the compiler, and are considered to be erroneous. Consider the following example:

with System; use System;
with System; use System;
procedure SliceUA is
   type AF is access all String;

   type A is access all String;
   for A'Size use Standard'Address_Size;

   procedure P (Arg : A) is
   begin
      if Arg'Length /= 6 then
         raise Program_Error;
      end if;
   end P;

   X : String := "hello world!";
   Y : AF := X (7 .. 12)'Unrestricted_Access;

begin
   P (A (Y));
end;

A normal unconstrained array value or a constrained array object marked as aliased has the bounds in memory just before the array, so a thin pointer can retrieve both the data and the bounds. But in this case, the non-aliased object X does not have the bounds before the string. If the size clause for type A were not present, then the pointer would be a fat pointer, where one component is a pointer to the bounds, and all would be well. But with the size clause present, the conversion from fat pointer to thin pointer in the call loses the bounds, and so this is erroneous, and the program likely raises a Program_Error exception.

In general, it is advisable to completely avoid mixing the use of thin pointers and the use of Unrestricted_Access where the designated type is an unconstrained array. The use of thin pointers should be restricted to cases of porting legacy code that implicitly assumes the size of pointers, and such code should not in any case be using this attribute.

Another erroneous situation arises if the attribute is applied to a constant. The resulting pointer can be used to access the constant, but the effect of trying to modify a constant in this manner is not well-defined. Consider this example:

P : constant Integer := 4;
type R is access all Integer;
RV : R := P'Unrestricted_Access;
..
RV.all := 3;

Here we attempt to modify the constant P from 4 to 3, but the compiler may or may not notice this attempt, and subsequent references to P may yield either the value 3 or the value 4 or the assignment may blow up if the compiler decides to put P in read-only memory. One particular case where Unrestricted_Access can be used in this way is to modify the value of an in parameter:

procedure K (S : in String) is
   type R is access all Character;
   RV : R := S (3)'Unrestricted_Access;
begin
   RV.all := 'a';
end;

In general this is a risky approach. It may appear to "work" but such uses of Unrestricted_Access are potentially non-portable, even from one version of GNAT to another, so are best avoided if possible.