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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.holsti@tidorum.invalid> wrote in message news:k94t2nFelgbU1@mid.individual.net...

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)