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!fu-berlin.de!uni-berlin.de!not-for-mail From: "Nick Roberts" Newsgroups: comp.lang.ada Subject: Re: Zero length Objects Date: Thu, 1 Jul 2004 15:11:43 +0100 Message-ID: <2kikcvF2r8ikU1@uni-berlin.de> References: <2kh2leF2ct4hU1@uni-berlin.de> X-Trace: news.uni-berlin.de OAtvKGTGB8WLIg+ENSubMg286bdusA/rRltR9mztPZ6zsLKlI= X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Xref: g2news1.google.com comp.lang.ada:2025 Date: 2004-07-01T15:11:43+01:00 List-Id: "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 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