Constancy of X'Address?

[Niklas Holsti]

A discussion in comp.arch (on the new C23 standard for C) brought up
these questions, which I could not answer with confidence:

- Is the address of an object constant in Ada? That is, if I have some
object X in an Ada program, do repeated applications of X'Address always
return the same value?

- Does the answer depend on how X is allocated (created): on the library
level, on the stack, or in a pool ("new")?

The issue behind this question is whether an Ada program could use
garbage collection that moves objects around, for example a compacting
collector.

[Maxim Reznik]

If the type of the object is limited, then the object address is a constant. For other objects there is no such guaranty I guess.

[Jeffrey R.Carter]

On 2023-04-05 11:24, Niklas Holsti wrote:
>
> - Is the address of an object constant in Ada? That is, if I have some object X
> in an Ada program, do repeated applications of X'Address always return the same
> value?
>
> - Does the answer depend on how X is allocated (created): on the library level,
> on the stack, or in a pool ("new")?

'Address is discussed in ARM 13.3
(http://www.ada-auth.org/standards/aarm12_w_tc1/html/AA-13-3.html). (12.c) says
"The validity of a given address depends on the run-time model; thus, in order
to use Address clauses correctly, one needs intimate knowledge of the run-time
model."

Under Implementation Advice, (15-16) say "The recommended level of support for
the Address attribute is:

"X'Address should produce a useful result if X is an object that is aliased or
of a by-reference type, or is an entity whose Address has been specified."

There is nothing specific about whether the value can change.

--
Jeff Carter
"We'll make Rock Ridge think it's a chicken
that got caught in a tractor's nuts!"
Blazing Saddles
87

[Randy Brukardt]

I agree with the other answers (for the most part). Not much is guarenteed
about 'Address. But by-reference and aliased objects have to *work* like
they are not moved. If the runtime can deal with moving such things, Ada
doesn't care.

As a practical matter, most Ada implementations assume objects don't move.
Janus/Ada assigns everything at compile-time, so the only time anything
moves is when it is created or destroyed.

The big problem with garbage collection in Ada is that early finalization is
not allowed (other than a few tiny exceptions in failure cases and [in
post-Ada 22] certain function results.) So any object that might have a
controlled part can never be garbage collected, even if there is no other
use or access to it.

Changing that is a very hard problem, as you cannot allow finalization to
happen at any instant or by any arbitrary task (if you did, every
finalization would be a race scenario, and every Finalize routine would need
dedicated locking). I've suggesting allowing it for "unreachable objects"
(not a useful definition by itself, it would need to be defined) at places
where masters are being exited anyway (so finalization should be expected at
those locations). But it's unclear if you can build a useful garbage
collector that way (and what the overhead would be).

Randy.



"Niklas Holsti" <niklas...@tidorum.invalid> wrote in message
news:k94t2n...@mid.individual.net...