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: a07f3367d7,7b60a2e8329f4e64 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.181.13.205 with SMTP id fa13mr1016118wid.3.1359079627063; Thu, 24 Jan 2013 18:07:07 -0800 (PST) Path: i11ni18214wiw.0!nntp.google.com!feeder1.cambriumusenet.nl!82.197.223.108.MISMATCH!feeder2.cambriumusenet.nl!feed.tweaknews.nl!194.109.133.87.MISMATCH!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!xlned.com!feeder3.xlned.com!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!news.bawue.net!storethat.news.telefonica.de!telefonica.de!newsout01.versatel.de!newsin01.versatel.de!news.tu-darmstadt.de!news.internetdienste.de!weretis.net!feeder1.news.weretis.net!usenet.pasdenom.info!dedibox.gegeweb.org!gegeweb.eu!nntpfeed.proxad.net!proxad.net!feeder2-2.proxad.net!nx02.iad01.newshosting.com!newshosting.com!69.16.185.11.MISMATCH!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post02.iad.highwinds-media.com!news.flashnewsgroups.com-b7.4zTQh5tI3A!not-for-mail From: Stephen Leake Newsgroups: comp.lang.ada Subject: Re: GNAT 4.4.5 Record Bit_Order Endian issues References: <20bda3de-b033-4b4e-8298-2ac47701b814@googlegroups.com> <0169b2ea-30b4-45d1-a4d4-c5841e54b9ad@googlegroups.com> <31facfa1-dae9-47c0-b5af-262e31c1d4f9@googlegroups.com> <63e09fad-16f0-468d-9d38-7969aaf3abe9@googlegroups.com> <8a7a9e6f-6f87-44a7-942b-2275a9ecf049@googlegroups.com> <61a24758-b289-40b0-9ee2-ad7feddff5c6@googlegroups.com> Date: Fri, 18 Jan 2013 20:48:07 -0500 Message-ID: <85fw1y2bag.fsf@stephe-leake.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (windows-nt) Cancel-Lock: sha1:y9M2mCseIuWAcxMrXJFEzALLs+g= MIME-Version: 1.0 X-Complaints-To: abuse@flashnewsgroups.com Organization: FlashNewsgroups.com X-Trace: e086250f9fb57e029e66119162 X-Received-Bytes: 2562 Content-Type: text/plain Date: 2013-01-18T20:48:07-05:00 List-Id: awdorrin writes: > So, I think I figured out how to solve my problem. Yes, I agree :) > 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 = BIG_ENDIAN then > -- legacy big endian byte copy > MEMCPY( Target => Track_Address, Source => Track_Rec'Address, Size => 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 := 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) := 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 Stream 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. That's what I do, but I use my own byte_swap package (which I believe I wrote before GNAT.Byte_Swapping was available). My code doesn't use address overlays, but that means it makes copies on the stack. For small data packets, this is not a problem. -- -- Stephe