Re: Zero length Objects

["Nick Roberts" <nick.roberts@acm.org>]

"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:MmlhKUHhwSXB@eisner.encompasserve.org...

> I don't understand how one can guarantee such non-conflicting
> encodings are possible on all architectures, particular when the
> compiler supports operating system programming in Ada.

I'm pretty sure that such a scheme would be feasible for just about any
target architecture. Even if an address is a simple linear memory address
(with no special bits at all) one word in size, and access values are
implemented as such an unadorned address, there will be significant areas of
memory which are known to be suitably invalid addresses.

The fact that we are not talking about access-to-subprogram types helps. For
any access-to-object type implemented as above, any value which is an
address pointing at code is invalid for dereferencing, and so suitable as an
invented value to 'reference' an object of zero size. An easy algorithm for
allocating such invented values would be to start at the memory location at
the beginning of program code (which is typically all gathered in one lump
on such machines) and work upwards. A range check can be used to check
dereferencing of access values.

For many architectures, there will be some encoding of access values that
cannot be any valid address, or which could reasonably be interpreted that
way. For example, on any 64-bit architecture, I think it would be reasonable
to use bit 63 (the uppermost bit) to flag invented values. Typically, the
hardware will provide the necessary dereference checking; you only need to
ensure nothing is ever allocated to the upper half the address range.

I'd prefer the new revision of the standard (Ada 2005) to mandate the
semantics which seem to be implied (although arguably) by the wording in the
Ada 95 RM (unchanged in the TC in 2000), which is inherited almost unchanged
from the Ada 83 LRM. I'd be happy for an implementation permission to allow
the semantics to be dropped when (and only when) they cannot be reasonably
supported (but I'd expect such circumstances to be rare, in reality). Maybe
in the /next/ revision.

-- 
Nick Roberts