[The attribute Unchecked_Access is used to create
access values in an unsafe manner — the programmer is responsible
for preventing “dangling references.”]
All rules and semantics that
apply to X'Access (see
3.10.2) apply also
to X'Unchecked_Access, except that, for the purposes of accessibility
rules and checks, it is as if X were declared immediately within a library
package.
{Access attribute: See also
Unchecked_Access attribute}
Reason: {
AI95-00254-01}
Such an attribute would allow unsafe “downward closures”,
where an access value designating a more nested subprogram is passed
to a less nested subprogram. (Anonymous access-to-subprogram parameters
provide safe “downward closures”.) This requires some means
of reconstructing the global environment for the more nested subprogram,
so that it can do up-level references to objects. The two methods of
implementing up-level references are displays and static links. If unsafe
downward closures were supported, each access-to-subprogram value would
have to carry the static link or display with it. We don't want to require
the space and time overhead of requiring the extra information for all
access-to-subprogram types, especially as including it would make interfacing
to other languages (like C) harder.
If desired, an instance of Unchecked_Conversion
can be used to create an access value of a global access-to-subprogram
type that designates a local subprogram. The semantics of using such
a value are not specified by the language. In particular, it is not specified
what happens if such subprograms make up-level references; even if the
frame being referenced still exists, the up-level reference might go
awry if the representation of a value of a global access-to-subprogram
type doesn't include a static link.