CVS difference for ais/ai-00133.txt

Differences between 1.5 and version 1.6
Log of other versions for file ais/ai-00133.txt

--- ais/ai-00133.txt	1999/08/11 22:04:31	1.5
+++ ais/ai-00133.txt	2001/09/08 01:42:46	1.6
@@ -532,3 +532,91 @@
 scalar.
 
 ****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, July 3, 2001  7:42 PM
+
+We suddenly had two of our large customer ask, just days apart, whether
+there was a way of controlling bit ordering in arrays.
+
+The answer of course is no, but it does seem that it would be perfectly
+reasonable to allow the specification of the Bit_Order attribute for an
+array type ...
+
+Thoughts?
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, July 3, 2001  8:14 PM
+
+Could you be a bit more specific on what the need/problem is? Off-hand, I
+can't think of anything having to do with arrays for which the bit ordering
+would matter. In particular, you don't specify bit numbers of arrays as you
+do with records.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, July 3, 2001  8:47 PM
+
+   type x is array (0 .. 7) of Boolean;
+   pragma Pack (x);
+
+now, which bit is x(0)?
+
+****************************************************************
+
+From: Robert Duff
+Sent: Thursday, July 5, 2001  11:52 AM
+
+So it matters if you unchecked_convert to a type T is range 0..2**7-1.
+The Bit_Order indicates whether x(0) is the low- or high-order bit
+of the integer.  Right?
+
+Now what if it's not packed?  Eg:
+
+    X: array (0 .. 15) of Boolean;
+
+Does Bit_Order control whether the array is stored backwards in memory
+(i.e., whether X(0)'Address = X'Address + 15)?
+
+If we have:
+
+    X: array (1 .. 100) of Character;
+    Y: array (1 .. 100) of Character;
+
+and X and Y are of different Bit_Order, and we unchecked convert X to Y,
+will Y(100) = X(1), and Y(99) = X(2)?
+
+Or what if it's packed, and bigger than a storage unit, or bigger than a
+word?
+
+I guess I'm confused about what the semantics should be when crossing
+byte or word boundaries.  I'm not sure I understand the issues for
+records, either.  :-(
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, July 5, 2001  12:26 PM
+
+Well bit order for records simply controls the numbering of bits WITHIN
+a storage unit, it has no effect on numbering of bytes. If you have fields
+that cross storage unit boundaries, there are two cases:
+
+1. The easy case, where the field occupies an integral number of bytes and
+completely occupies these bytes, e.g. a 32 bit field occupying four bytes.
+In this case, bit order has no relevance in any case, since the field will
+simply occupy these four bytes.
+
+2. The hard case, where the field occupies part of a byte and crosses
+byte boundaries. In this case the specification of a non-standard bit
+order results in non-contiguous fields, and is a mess. GNAT simply disallows
+the specification of bit order for any record with such a field.
+
+For arrays, I think it only makes sense to worry about the case of 1,2,4
+bits where every element lies entirely within a storage unit, and in that
+case bit order makes perfectly good sense.
+
+****************************************************************

Questions? Ask the ACAA Technical Agent