> > Object'Size Object'Size/8 (Object'Size+7)/8
> > 1 0 1
> > 5 0 1
> > 7 0 1
> > 8 1 1
> > 9 1 2
> I think you are missing the difference between Type'Size and Object'Size in
> Ada 95. Type'Size is the minimal required size in a packed record, and
> Object'Size is something else, and should be a multiple of the type's
> alignment (I recommend you re-read RM 13.3). Note that Object'Size will almost
> never be 1, 5, 7 or 9 as in your table above, but Type'Size could.
I retract part of my comments: I think "size of representation" (RM95) is
_less_ clear than "number of bits allocated to hold" (LRM83). If the
value is decimal 10 and the range is 0 .. 12, and memory contains the bits
00000000 00000000 00000000 00001010 00000000
A A+1 A+2 A+3 A+4
then who is to say what the representation is? Vendor A says the size of
the representation is 8, the vendor B says it's 4. Under Ada 83 _and_ an
earlier version, the vendor B said the number of bits allocated was 32.
What I wasn't told until after I wrote all the other stuff is that _both_
of the vendor B's compilers said the 'Address is A. So there seems no way
to write generic code capable of using 'Size and 'Address to locate the
actual bits of an object.
RM95 13.3(43) does not require the 'Size to be a multiple of the
alignment. Rather, it says that IF the size is a multiple of the
alignment, then something else is only recommended.
RM95 13.3(50) recommends that the object size equal the subtype size IF
the subtype size is specified (it isn't).
However, one thing I AM still sure of: the correct way to compute the
number of octets needed to hold XXX bits is (XXX+7)/8 _not_ XXX/8