Unrestricted_Access attribute is similar to
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.
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
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
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
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.