Re: Is this a GNAT bug???

[Mark Johnson <mark_h_johnson@raytheon.com>]

Robert Quinn wrote:
> [snip]
> I guess the scenario I'm thinking of must not occur too frequently.
> I'll use specific numbers to make the example simple.  Suppose you
> have a sequence of 12 bytes 94 bits).  Suppose the first and last byte
> are header/tail info, leaving 10 bytes for data.  Suppose 65 bits of
> the 10 bytes represent one kind of data, the remaining 13 bits another
> kind of data.
This is going to be hard on several platforms - especially if
portability is to be considered. We are in the process of rehosting a
large SGI application (VADS) to PC's (GNAT) and we have several places
in our code where we had to address bit and byte order differences.
Annex C compliance means that all the Section 13 recommendations are
supported. What you describe does not appear to fit those
recommendations.

You may be better off with declarations that define the "data" in
smaller chunks (e.g., a sequence of bytes) and use functions to extract
and fill in the values needed. For example, based on the default bit
order, the array you defined can be represented in the following ways on
a big & little endian machine.

Big endian (Bit_Order == System.High_Order_First)
Byte 00000000 11111111 22222222 33333333 ...
Bit  01234567 01234567 01234567 01234567 ...
Ind  00000000 00111111 11112222 22222233
-ex  01234567 89012345 67890123 45678901

Little endian (Bit_Order == System.Low_Order_First)
Byte 00000000 11111111 22222222 33333333 ...
Bit  76543210 76543210 76543210 76543210 ...
Ind  00000000 11111100 22221111 33222222
-ex  76543210 54321098 32109876 10987654

Where the byte & bit offset are the first two rows & the last two rows
represent the index into the bit array (0..31 shown). Basically the rule
is to normalize to "Storage_Unit" (in this case 8) and then use the
specified (usually default) bit order for the order of bits. The
annotated ARM (13.5.1 and 13.5.2) has more explanation of this if
needed.

We had a few cases of these & had to swap the bits and the bytes [sigh]
to otherwise preserve the coding style. In other cases, we were able to
override the default bit order and get what we wanted. For type T, you
can set T'Bit_Order to High or Low_Order_First, but that doesn't solve
all the problems - I can list a few if needed.

Putting a level of abstraction around the data is probably best to hide
this kind of manipulation.

[snip]
> I could convert the sequence of bytes to an access type to this
> record.  For example:
> 
> type Message_Type_Access is access Message_Type;
> function Get_Message_Data is new Unchecked_Conversion
>    (SOURCE => System.ADDRESS,
>     TARGET => Message_Type_Access);
> 
How about System.Address_To_Access_Conversions [13.7.2] instead? Read
the definition carefully, we screwed up one one such conversion when
making the change.

[snip]

> So reading a sequence of bits >= 65 bits out of memory is just always
> going to be more work since you cannot convert it directly into a
> type, right?
> 
Actually, depending on the platform, 65 may be 33 - or in the future
129. Another reason to try to encapsulate the awful code and hide it
from the rest of your application.
  --Mark