13.7.2 The Package System.Address_To_Access_Conversions
Static Semantics
1
The following language-defined
generic library package exists:
2
generic
type Object(<>)
is limited private;
package System.Address_To_Access_Conversions
is
pragma Preelaborate(Address_To_Access_Conversions);
3/2
{
AI05-0229-1}
type Object_Pointer
is access all Object;
function To_Pointer(Value : Address)
return Object_Pointer
with Convention => Intrinsic;
function To_Address(Value : Object_Pointer)
return Address
with Convention => Intrinsic;
4/3
{
AI05-0229-1}
pragma Convention(Intrinsic, To_Pointer);
pragma Convention(Intrinsic, To_Address);
end System.Address_To_Access_Conversions;
5/2
{
AI95-00230-01}
The To_Pointer and To_Address subprograms convert back and forth between
values of types Object_Pointer and Address. To_Pointer(X'Address) is
equal to X'Unchecked_Access for any X that allows Unchecked_Access. To_Pointer(Null_Address)
returns
null.
For other addresses, the behavior
is unspecified. To_Address(
null) returns Null_Address
(for null of the appropriate type). To_Address(Y), where
Y /=
null, returns Y.
all'Address.
5.a/3
Discussion: {
AI95-00114-01}
{
AI05-0005-1}
The programmer should ensure that the address passed to To_Pointer is
either Null_Address, or the address of an object of type Object.
(If
Object is not a not
by-reference type, the object ought
to be aliased; recall that the Address attribute is not required to provide
a useful result for other
objects.) Otherwise, the behavior of the program is unspecified;
it might raise an exception or crash, for example.
5.b
Reason: Unspecified is almost the same
thing as erroneous; they both allow arbitrarily bad behavior. We don't
say erroneous here, because the implementation might allow the address
passed to To_Pointer to point at some memory that just happens to “look
like” an object of type Object. That's not necessarily an error;
it's just not portable. However, if the actual type passed to Object
is (for example) an array type, the programmer would need to be aware
of any dope that the implementation expects to exist, when passing an
address that did not come from the Address attribute of an object of
type Object.
5.c
One might wonder why To_Pointer and To_Address
are any better than unchecked conversions. The answer is that Address
does not necessarily have the same representation as an access type.
For example, an access value might point at the bounds of an array when
an address would point at the first element. Or an access value might
be an offset in words from someplace, whereas an address might be an
offset in bytes from the beginning of memory.
Implementation Permissions
6
An implementation may place restrictions on instantiations
of Address_To_Access_Conversions.
6.a
Ramification: For example, if the hardware
requires aligned loads and stores, then dereferencing an access value
that is not properly aligned might raise an exception.
6.b
For another example, if the implementation has
chosen to use negative component offsets (from an access value), it might
not be possible to preserve the semantics, since negative offsets from
the Address are not allowed. (The Address attribute always points at
“the first of the storage elements....”) Note that while
the implementation knows how to convert an access value into an address,
it might not be able to do the reverse. To avoid generic contract model
violations, the restriction might have to be detected at run time in
some cases.
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe
