Contents Index Search Previous Next
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
type Object_Pointer is access all Object;
function To_Pointer(Value : Address) return Object_Pointer;
function To_Address(Value : Object_Pointer) return Address;
4
pragma Convention(Intrinsic, To_Pointer);
pragma Convention(Intrinsic, To_Address);
end System.Address_To_Access_Conversions;
5
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.
{unspecified
[partial]} 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
Discussion: The programmer
should ensure that the address passed to To_Pointer is either Null_Address,
or the address of an object of type Object. 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.
Contents Index Search Previous Next Legal