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,
	MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,d233b131fc3b7ba7
X-Google-Attributes: gid103376,public
From: Adrian Hoe <byhoe@my-deja.com>
Subject: Re: Help: Storage size
Date: 1999/07/16
Message-ID: <7mmf9f$5le$1@nnrp1.deja.com>#1/1
X-Deja-AN: 501603552
References: <7mejue$9lk$1@nnrp1.deja.com> <7mf7lp$c9g@hobbes.crc.com>
 <7mfndb$mc8$1@nnrp1.deja.com> <7mfs92$jch@hobbes.crc.com>
X-Http-Proxy: 1.0 x26.deja.com:80 (Squid/1.1.22) for client 202.188.11.156
Organization: Deja.com - Share what you know. Learn what you don't.
X-Article-Creation-Date: Fri Jul 16 05:17:42 1999 GMT
X-MyDeja-Info: XMYDJUIDbyhoe
Newsgroups: comp.lang.ada
X-Http-User-Agent: Mozilla/4.04C-Caldera [en] (X11; I; Linux 2.0.33 i486)
Date: 1999-07-16T00:00:00+00:00
List-Id: <comp.lang.ada>

In article <7mfs92$jch@hobbes.crc.com>,
  "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote:
>
> If you want to be assured that your types have the correct size,
> then I would not recommend basing your types on
> Interfaces.C.Unsigned_Short, because that type is dependent on the
size
> of C's unsigned short type for that platform.
>
> How about starting from scratch -- e.g.:
>
>    type Card8 is mod 2 ** 8;
>    for Card8'size use 8;
>    type Card16 is mod 2 ** 16;
>    for Card16'size use 16;
>
>    type Treq is record
>       ReqType : Card8;
>       Length  : Card16;
>    end record;
>
>    for Treq use record
>       ReqType at 0 range 0 .. 7;
>       Length  at 2 range 0 .. 15;
>    end record;
>
>    for Treq'size use 32;
>
> Note that there is one byte of unocupied space between the
> record components, consistent with the way gcc lays out
> your struct, in the absence of #pragma pack.


In case of the above implementation, how can one determine  the one
unoccupied byte between the two record components? Is this compiler or
platform dependable? In such cases, what will happen to the following
implementation:

   type Card8 is mod 2 ** 8;
   for Card8'size use 8;
   type Card16 is mod 2 ** 16;
   for Card16'size use 16;

   type Int32 is range -2 ** 31 .. (2 ** 31) - 1;
   for Int32'Size use 32;
   subtype Long is Int32;

   type Float64 is digits 15;
   subtype Long_Flt is Float64;

   Word_Size : constant POSITIVE := Long'Size / 8;

   type TReq is
      record
         ReqType  : Card8;
         Length   : Card16;
         Distance : Long_Flt;
      end record;

   for TReq use
      record
         ReqType  at 0 * Word_Size     range 0 .. 7;
         Length   at 0 * Word_Size + 2 range 0 .. 15
         Distance at 2 * Word_Size     range 0 .. 63;
      end record;


There will be one unoccupied byte between ReqType and Length and 4
unoccupied byte between Length and Distance. The record will be padded
to 32-bit spaces. Is this correct?

If Yes, is this portable to 64-bit platform such as UltraSPARC? Or in
the case of UltraSPARC, the record will be padded to 64-bit space?
--
Adrian BY, Hoe
--------------


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.