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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,5850c59062ca527a
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 1994-11-04 07:36:28 PST
Path: 
 bga.com!news.sprintlink.net!howland.reston.ans.net!europa.eng.gtefsd.com!news.mathworks.com!news.duke.edu!eff!blanket.mitre.org!linus.mitre.org!linus!mbunix!eachus
From: eachus@spectre.mitre.org (Robert I. Eachus)
Newsgroups: comp.lang.ada
Subject: Re: Type System.ADDRESS
Date: 3 Nov 94 10:08:41
Organization: The Mitre Corp., Bedford, MA.
Distribution: world
Message-ID: <EACHUS.94Nov3100841@spectre.mitre.org>
References: <393k18$huv@theopolis.orl.mmc.com>
NNTP-Posting-Host: spectre.mitre.org
In-reply-to: rgilbert@orl.mmc.com's message of 31 Oct 1994 20:28:24 GMT
Date: 1994-11-03T10:08:41+00:00
List-Id: <comp.lang.ada>


In article <393k18$huv@theopolis.orl.mmc.com> rgilbert@orl.mmc.com (Bob Gilbert) writes:

 > I've run across a problem and would like a little net wisdom
 > on this...

 > The compiler I'm working with has choosen to implement the type
 > System.ADDRESS as static.  Although this appears to be within 
 > the rules of the LRM, it does present some significant limitations.

  Huh?  type System.ADDRESS should always be static (although since it
is implementation defined, it doesn't need to be an integer type.

  If you mean that the address in an Address clause is required to be
static, this is wrong.  RM13.1(10) allows an implementation to limit
representation clauses "to those that can be handled simply by the
underlying hardware." However staticness is a compile-time vs.
run-time issue that has nothing to do with the actual hardware.

 > Is it reasonable for a compiler to implement System.ADDRESS as static?  
Yes. (See above.)

 > Is it reasonable for the language to allow this?
Same answer.

 > Is there a better way to work around the limitations?
Do you have a support contract with the vendor?  If so make it his
problem.


--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...