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.74.141 with SMTP id t13mr974219wiv.5.1359079518878;
        Thu, 24 Jan 2013 18:05:18 -0800 (PST)
Path: 
 i11ni18198wiw.0!nntp.google.com!feeder1.cambriumusenet.nl!82.197.223.108.MISMATCH!feeder2.cambriumusenet.nl!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!news-1.dfn.de!news.dfn.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Niklas Holsti <niklas.holsti@tidorum.invalid>
Newsgroups: comp.lang.ada
Subject: Re: GNAT 4.4.5 Record Bit_Order Endian issues
Date: Fri, 18 Jan 2013 17:28:09 +0200
Organization: Tidorum Ltd
Message-ID: <alt809FcfavU1@mid.individual.net>
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>
 <kdap96$ic2$1@dont-email.me>
Mime-Version: 1.0
X-Trace: individual.net
 Y10yjVI5XIk4V3m3ZMo7iwcBT0U/K66KZTRXdFGJ6c/4qWcOQeTrKUgrv7UrL0cJEE
Cancel-Lock: sha1:d36FQqx69DA3i1EdC43nyLD+300=
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
 rv:17.0) Gecko/20130107 Thunderbird/17.0.2
In-Reply-To: <kdap96$ic2$1@dont-email.me>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Date: 2013-01-18T17:28:09+02:00
List-Id: <comp.lang.ada>

On 13-01-18 08:15 , J-P. Rosen wrote:

> Regarding the use of "at": you can always use 0 and number the bits
> starting from the beginning of the record (and bit numbers are not
> limited to 31).

Except that if you use the non-default bit order, then the bit numbers
are limited by the number of bits in the "largest machine scalar", per
RM 13.5.1(10.2/2), except in a special case (10.3/2).

Which means, for a portable program where you don't know what the
default bit order will be on some platform, nor know what size scalars
that platform has, you had best limit the bit numbers to a very
conservative range.

I have stopped using record representation clauses in portable Ada
programs and prefer to access bit-fields by shifting and masking. Sorry
to say.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .