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.180.79.69 with SMTP id h5mr973004wix.6.1359079546244;
        Thu, 24 Jan 2013 18:05:46 -0800 (PST)
Path: 
 o9ni18185wio.1!nntp.google.com!feeder1.cambriumusenet.nl!82.197.223.103.MISMATCH!feeder3.cambriumusenet.nl!feed.tweaknews.nl!193.141.40.65.MISMATCH!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!news.bawue.net!storethat.news.telefonica.de!telefonica.de!serpens!newsmonster.de!news1.tnib.de!feed.news.tnib.de!news.tnib.de!weretis.net!feeder4.news.weretis.net!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail
From: Simon Wright <simon@pushface.org>
Newsgroups: comp.lang.ada
Subject: Re: GNAT 4.4.5 Record Bit_Order Endian issues
Date: Fri, 18 Jan 2013 17:19:20 +0000
Organization: A noiseless patient Spider
Message-ID: <lyy5fqtnmv.fsf@pushface.org>
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>
Mime-Version: 1.0
Injection-Info: mx04.eternal-september.org;
 posting-host="6d11d42385b58e82a68a7c31ea9c32ac";
	logging-data="16627"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1/g2bw9iTcvdhSnkj6rtYoItzFU+HibHN4="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (darwin)
Cancel-Lock: sha1:9qJHUJKizmZlrauSkxpXTuTwXB0=
	sha1:Bh7iFJbeXfIvlR7ls0E9frB/qf8=
Content-Type: text/plain
Date: 2013-01-18T17:19:20+00:00
List-Id: <comp.lang.ada>

awdorrin <awdorrin@gmail.com> writes:

> Presumably, if the record contents can be defined in terms of a 32-bit
> machine scalar' - then this endian conversion can be done by starting
> at 'MyTrkRec'Address' and doing byte swaps on 4-byte (32-bit)
> groupings.
>
> In C I'd simply make a 'uint32_t' pointer to the record address, and
> loop through till the end of the record doing 'htonl()' calls. But Ada
> doesn't make things quite so 'easy' ;-)

Provided all your machine scalars are 32-bits. I've come across layouts
where htons() was needed (twice).

I wrote a toy to give myself some confidence about this - at
http://dl.dropbox.com/u/34783908/Ada/endianness.adb