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,FREEMAIL_FROM
	autolearn=ham autolearn_force=no version=3.4.4
X-Google-Thread: a07f3367d7,7b60a2e8329f4e64
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII-7-bit
X-Received: by 10.224.218.2 with SMTP id ho2mr5420452qab.8.1358521867340;
        Fri, 18 Jan 2013 07:11:07 -0800 (PST)
X-Received: by 10.49.94.129 with SMTP id dc1mr2123212qeb.22.1358521867251;
 Fri, 18 Jan 2013 07:11:07 -0800 (PST)
Path: 
 k2ni675qap.0!nntp.google.com!p13no1252321qai.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Fri, 18 Jan 2013 07:11:07 -0800 (PST)
In-Reply-To: <8a7a9e6f-6f87-44a7-942b-2275a9ecf049@googlegroups.com>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com;
 posting-host=192.31.106.36;
 posting-account=YkFdLgoAAADpWnfCBA6ZXMWTz2zHNd0j
NNTP-Posting-Host: 192.31.106.36
References: <20bda3de-b033-4b4e-8298-2ac47701b814@googlegroups.com>
 <0169b2ea-30b4-45d1-a4d4-c5841e54b9ad@googlegroups.com>
 <ly38xzv86c.fsf@pushface.org>
 <31facfa1-dae9-47c0-b5af-262e31c1d4f9@googlegroups.com>
 <63e09fad-16f0-468d-9d38-7969aaf3abe9@googlegroups.com>
 <8a7a9e6f-6f87-44a7-942b-2275a9ecf049@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <61a24758-b289-40b0-9ee2-ad7feddff5c6@googlegroups.com>
Subject: Re: GNAT 4.4.5 Record Bit_Order Endian issues
From: awdorrin <awdorrin@gmail.com>
Injection-Date: Fri, 18 Jan 2013 15:11:07 +0000
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Date: 2013-01-18T07:11:07-08:00
List-Id: <comp.lang.ada>

So, I think I figured out how to solve my problem.

Within the legacy code, the representation clause was used to define the me=
mory locations, then the record was being copied to/from a buffer via an im=
ported 'memcpy' call. It worked since the system was Big Endian, but obviou=
sly it is non-portable to a Little Endian system.

What I realize now is, if I define the record using 'Bit_Order =3D System.H=
igh_Order_First; and then define the record elements in terms of a chosen m=
achine scalar type (ie. 32-bit)

Now, the record specification will define 'equivalent' record structures, w=
hen endian swapping is taken into account.

The following code is probably not the most elegant way to solve this (and =
I'm open to suggestions) but here it is:

if Standard'Default_Bit_Order =3D BIG_ENDIAN then
  -- legacy big endian byte copy
  MEMCPY( Target =3D> Track_Address, Source =3D> Track_Rec'Address, Size =
=3D> Track_Rec'Size/8);
else
  -- little endian convert to big endian by 32-bit word
  declare
    type EndCvtArray is array(UInt32 range <> ) of UInt32;
    WrdCnt : constant UInt32 :=3D Track_Rec'Size/32;
    Target : EndCvtArray(1..WrdCnt);
    for Target'Address use Track_Address; -- overlay
    Source : EndCvtArray(1..WrdCnt);
    for Source'Address use Track_Rec'Address; -- overlay
  begin
    for i in 1..WrdCnt loop
      Target(i) :=3D SwapUInt32(Source(i));
    end loop;
  end;
end if;

function SwapUIn32 is new GNAT.Byte_Swapping.Swapped4(UInt32);

I'm guessing there might be some cleaner way to do this, perhaps using Stre=
am IO. But I tried the code and it appears to work.

Once I understood that the representation clause wasn't defining the memory=
 locations, this made a lot more sense.