From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,85c4b961f840b5ab X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!news.illinois.net!attcg1!ip.att.net!news.binc.net!kilgallen From: Kilgallen@SpamCop.net (Larry Kilgallen) Newsgroups: comp.lang.ada Subject: Re: Zero length Objects Date: 1 Jul 2004 10:42:18 -0500 Organization: LJK Software Message-ID: References: <2kh2leF2ct4hU1@uni-berlin.de> <2kikcvF2r8ikU1@uni-berlin.de> NNTP-Posting-Host: eisner.encompasserve.org X-Trace: grandcanyon.binc.net 1088696469 26305 192.135.80.34 (1 Jul 2004 15:41:09 GMT) X-Complaints-To: abuse@binc.net NNTP-Posting-Date: Thu, 1 Jul 2004 15:41:09 +0000 (UTC) Xref: g2news1.google.com comp.lang.ada:2031 Date: 2004-07-01T10:42:18-05:00 List-Id: In article <2kikcvF2r8ikU1@uni-berlin.de>, "Nick Roberts" writes: > "Larry Kilgallen" 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.