comp.lang.ada
 help / color / mirror / Atom feed
From: Kilgallen@SpamCop.net (Larry Kilgallen)
Subject: Re: Zero length Objects
Date: 1 Jul 2004 10:42:18 -0500
Date: 2004-07-01T10:42:18-05:00	[thread overview]
Message-ID: <agToHcc+JsKF@eisner.encompasserve.org> (raw)
In-Reply-To: 2kikcvF2r8ikU1@uni-berlin.de

In article <2kikcvF2r8ikU1@uni-berlin.de>, "Nick Roberts" <nick.roberts@acm.org> writes:
> "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

I did not realize that.

> 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.

On VMS program code is "typically" gathered together, but not "necessarily".

> 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.

But that really is the territory of the operating system (if any).
Today VMS does not use that range, but there is no commitment it will
not use it in the future.



  reply	other threads:[~2004-07-01 15:42 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-30  5:55 Zero length Objects Robert C. Leif
2004-06-30 20:32 ` Jacob Sparre Andersen
2004-06-30 21:01 ` Frank J. Lhota
2004-07-01  0:02   ` Nick Roberts
2004-07-01  1:28     ` Georg Bauhaus
2004-07-01 10:37       ` Björn Persson
2004-07-01 11:25     ` Larry Kilgallen
2004-07-01 14:11       ` Nick Roberts
2004-07-01 15:42         ` Larry Kilgallen [this message]
2004-07-01 14:06     ` Xenos
2004-07-01 15:26       ` Nick Roberts
2004-07-02  1:06         ` Jeffrey Carter
2004-07-01  0:47   ` Brian May
2004-07-01 13:32     ` Frank J. Lhota
2004-07-01 14:52       ` Nick Roberts
2004-07-01 15:03         ` Xenos
2004-07-01 15:57           ` Hyman Rosen
2004-07-01 16:05             ` Xenos
2004-07-02 15:02               ` Frank J. Lhota
2004-07-02 15:11                 ` Adrian Knoth
2004-07-02 15:43                   ` Frank J. Lhota
2004-07-02 19:01                     ` Vinzent 'Gadget' Hoefler
2004-07-02 19:07                       ` Adrian Knoth
2004-07-02 19:25                         ` Vinzent 'Gadget' Hoefler
2004-07-02 21:06                           ` Xenos
2004-07-02 21:56                             ` Vinzent 'Gadget' Hoefler
  -- strict thread matches above, loose matches on Subject: below --
2004-07-02  8:30 Christoph Karl Walter Grein
2004-07-06 11:59 ` Nick Roberts
2004-07-06 22:14   ` Randy Brukardt
2004-07-06 22:28     ` Nick Roberts
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox