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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,83d7c4caadb45100 X-Google-Attributes: gid103376,public From: Stuart Palin Subject: Re: DECAda/VMS - calling GETJPI Date: 1996/06/03 Message-ID: <4ouo97$pe8@gcsin3.geccs.gecm.com>#1/1 X-Deja-AN: 158214519 references: <31B2AF74.668E@dial.eunet.ch> to: Alan,Paterson, content-type: text/plain; charset=us-ascii organization: GEC Marconi Avionics (Rochester) mime-version: 1.0 newsgroups: comp.lang.ada x-mailer: Mozilla 1.2 (Windows; I; 16bit) Date: 1996-06-03T00:00:00+00:00 List-Id: I've no specific experience of using DEC Ada with GETJPI but this looks very similar to the general problem Ada 83 has with unsigned integers. Basically an unsigned type must be bound by an integer range constraint (LRM 3.5.4 (3)). An unsigned longword usually creates a problem since the base type integer is also usally longword based. This means the upper constarint on unsigned_longword is 2**32-1 which is not a valid integer expression (integer'last = 2**31-1). Many implementations (certainly the version of DEC Ada I am using) gets around this by defining the unsigned_longword as: unsigned_longword is range -2**31..2**31-1; -- or something equivalent This creates all sorts of problems for defining values in the upper range (16#80000000# .. 16#FFFFFFFF#) since they map on to negative values (but the bit image is correct!!). A reasonable way of accessing these values is to define a constant: Hex_80000000 : constant unsigned_longword(-16#80000000#); Now you can do things such as: ulong := Hex_80000000 + 16#456789AB#; Now for your -1 value what you need to use is 16#FFFFFFFF#; (which is the bit image equivalent of the longword integer representation of -1); this could be defined as a constant: Hex_FFFFFFFF : constant unsigned_longword(-1); though you will probably want to use a name more appropriate to your application. -- Stuart Palin | GEC Marconi Avionics Ltd Consultant Engineer | Airport Works Flight Systems Division | Rochester G-NET 791 4197 | Kent. ME1 2XX