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
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,81bce7ee9133fb42
X-Google-Attributes: gid103376,public
From: dewar@cs.nyu.edu (Robert Dewar)
Subject: Re: GNAT Ada for DOS - Reading Integers Problem
Date: 1996/02/21
Message-ID: <dewar.824906918@schonberg>#1/1
X-Deja-AN: 140391957
references: <4g2efj$d5d@susscsc1.rdg.ac.uk> <tgmDMwoGx.B04@netcom.com>
 <Dn33HL.ICr@lazrus.cca.rockwell.com> <4gdivm$10f5@watnews1.watson.ibm.com>
organization: Courant Institute of Mathematical Sciences
newsgroups: comp.lang.ada
Date: 1996-02-21T00:00:00+00:00
List-Id: <comp.lang.ada>

Norman says

"No, the purpose of the 'Bit_Order attribute is not to perform
big-endian/little-endian data conversion at run-time, but to assert that
bit numbers in record-representation clauses should be interpreted at
compile time according to either big-endian or little-endian conventions."

That's wrong, if a compiler DOES allow this compile time control, then
normal change-of-representation coding (i.e. have two derived types, one
with one bit order and one with the other, and use conversions to flip
between the two) should work fine.

Implementing the unnatural order is non-trivial (and implementing the
above change of representation even more non-trivial). Furthermore the
RM does not require this feature be implemented, so don't count on it
being available!