Re: GNAT 4.4.5 Record Bit_Order Endian issues

[Adam Beneschan <adam@irvine.com>]

On Monday, January 14, 2013 9:43:51 AM UTC-8, awdorrin wrote:
> I have a record with specification definition that starts, using big endian notation, with:
> 
> for TRACK_RECORD_TYPE use
>  record
>   TRACK_ID at 0 range 0 .. 11;
>   TRACK_ID_CNT at 1 range 4 .. 9;
>    ...
> 
> 
> The meaning being that the first 12 bits hold a track id and the next 6 bits hold the Count value.
> 
> I have had success in the past, using the gnat 4.4.5 compiler under Debian 6.0.6, to use the directive: for TRACK_RECORD_TYPE'Bit_Order use System.High_Order_First;
> 
> In order to continue using the definition in the big endian notation.
> 
> From the build output, the Bit_Order flag at first appears to be processed correctly, with the built compiler flags displaying to translated little endian definition as:
> 
> 
> 
> for TRACK_RECORD_TYPE use
>  record
>   TRACK_ID at 0 range 4 .. 15;
>   TRACK_ID_CNT at 1 range 11 .. 6;
>    ...
> 
> But the TRACK_ID_CNT range does not provide the proper definition.
> I believe it should be: TRACK_ID_CNT at 1 range 5 .. 0
> 
> Using the following code:
> 
> TRK_REC.TRACK_ID := 1;
> Text_IO.Put_Line("A: TRK_REC.TRACK_ID = " & Int32'Image(TRK_REC.TRACK_ID));
> TRK_REC.TRACK_ID_CNT := 1;
> Text_IO.Put_Line("B: TRK_REC.TRACK_ID = " & Int32'Image(TRK_REC.TRACK_ID));
> 
> The output displayed is:
> 
> A: TRK_REC.TRACK_ID = 1
> B: TRK_REC.TRACK_ID = 1025
> 
> Apparently because the TRACK_ID field is being read as a 16-bit value where:
> 
> "0000 0100 0000 0001" -> "BBBB CCAA AAAA AAAA"
> where the 'A' bits are the TRACK_ID and the B bits are part of the TRACK_ID_CNT field, and the 'C' bits are an overlap of the second variable, due to the improper definition translation.
> 
> Not sure if this 'bug' would be fixed in a newer version of the GNAT compiler or not.

Well, it looks to me like there's definitely a bug in there, unless your record is an Unchecked_Union.  If the fields really do overlap, the program should not compile; the language doesn't allow overlapping fields except in variant record cases (13.5.1(11)).  And if they don't overlap, then of course setting one component should not affect the value of the other one.

                               -- Adam