What shoudl GNAT do wrt variant record and representation clauses?

What shoudl GNAT do wrt variant record and representation clauses?

[Lucretia]

Hi,

I've been back on SDLAda, one bit I've been dreading, setting up a unit test to check to make sure my representations of the pixel formats are the same as what the C macros produce.

Well, I was getting an inconsistent failure, so I printed out both numbers in base 2, but multiple invocations caused 1 bit to be set or unset depending on the call:

<log>
Pixel_Format_Index_1_LSB (2#10001000100000000000100000000#) /= C_Index_1_LSB (2#10001000100000000000100000000#)
Pixel_Format_Index_1_MSB (2#10001101000000000000100000000#) /= C_Index_1_MSB (2#10001001000000000000100000000#)

FAIL Pixel format test
    Pixel_Format_Index_1_MSB (2#10001101000000000000100000000#) /= C_Index_1_MSB (2#10001001000000000000100000000#)
    at pixel_format_test_cases.adb:75

Total Tests Run:   1
Successful Tests:  0
Failed Assertions: 1
Unexpected Errors: 0
laguest@rogue ~/src/mine/sdlada $ ./build_unit_tests/unit_tests 
Pixel_Format_Index_1_LSB (2#10001000100000000000100000000#) /= C_Index_1_LSB (2#10001000100000000000100000000#)
Pixel_Format_Index_1_MSB (2#10001001000000000000100000000#) /= C_Index_1_MSB (2#10001001000000000000100000000#)

OK Pixel format test

Total Tests Run:   1
Successful Tests:  1
Failed Assertions: 0
Unexpected Errors: 0
</log>

Couldn't see anything wrong, took a break, came back and looked at the record in question:

<code>
   type Pixel_Orders (Pixel_Type : Pixel_Types := Unknown) is
      record
         case Pixel_Type is
            when Index_1 | Index_4 | Index_8 =>
               Indexed_Order : Bitmap_Pixel_Order;

            when Packed_8 | Packed_16 | Packed_32 =>
               Packed_Order  : Packed_Component_Order;

            when Array_U8 | Array_U16 | Array_U32 | Array_F16 | Array_F32 =>
               Array_Order   : Array_Component_Order;

            when others =>
               null;
         end case;
      end record with
        Unchecked_Union => True,
        Convention      => C,
        Size            => 4;

   for Pixel_Orders use
      record
         Indexed_Order at 0 range 0 .. 2;
         Packed_Order  at 0 range 0 .. 3;
         Array_Order   at 0 range 0 .. 3;
      end record;
</code>

The full source is here: https://github.com/Lucretia/sdlada/blob/master/src/sdl-video-pixel_formats.ads

I changed the Indexed_Order range to finish at bit 3, like the others. Compiled and ran, it worked. Multiple times in a row, I kept trying. Still working. 

So, is this correct behaviour? If so, is there a compiler flag to catch this?

Thanks,
Luke.

Re: What shoudl GNAT do wrt variant record and representation clauses?

[jsquirek]

Hey Luke,

The default for all enumerated types is a 4 byte integer is this correct?

I think that since the record is an unchecked union making the ranges of the members different may have caused some undesirable behavior. I might try playing around with unchecked unions and see if I get similar results.

Re: What shoudl GNAT do wrt variant record and representation clauses?

[Lucretia]

On Monday, 2 February 2015 07:45:14 UTC, jsqu...@gmail.com  wrote:
> Hey Luke,
> 
> The default for all enumerated types is a 4 byte integer is this correct?
> 
> I think that since the record is an unchecked union making the ranges of the members different may have caused some undesirable behavior. I might try playing around with unchecked unions and see if I get similar results.

no, that record is bits wide when used within the final record. they are all convention => C.

Re: What shoudl GNAT do wrt variant record and representation clauses?

[Simon Wright]

Lucretia <laguest9000@googlemail.com> writes:

>    for Pixel_Orders use
>       record
>          Indexed_Order at 0 range 0 .. 2;
>          Packed_Order  at 0 range 0 .. 3;
>          Array_Order   at 0 range 0 .. 3;
>       end record;

Pretty sure you're saying that you don't care what the top bit of the
4-bit field is if it contains an Indexed_Order. So sometimes it'll be
wrong.

I must say, since you're setting up constants, I'd have expected the
compiler to work out the required 32-bit Pixel_Format_Names value at
compile time from a zeroed base!

I wondered whether -gnatw.h would do the trick, but (4.9.1) it just says

gcc -c -gnatw.h pixel_formats.ads
pixel_formats.ads:124:10: warning: 32768-bit gap before component "Indexed_Order"
pixel_formats.ads:125:10: warning: 32768-bit gap before component "Packed_Order"
pixel_formats.ads:126:10: warning: 32768-bit gap before component "Array_Order"

:-)

(I changed the name of the package to save trouble downloading other stuff)

Re: What shoudl GNAT do wrt variant record and representation clauses?

[Stephen Leake]

Lucretia <laguest9000@googlemail.com> writes:

> Hi,
>
> I've been back on SDLAda, one bit I've been dreading, setting up a
> unit test to check to make sure my representations of the pixel
> formats are the same as what the C macros produce.

Use -fdump-ada-spec, then you don't need to write records or tests.

>    type Pixel_Orders (Pixel_Type : Pixel_Types := Unknown) is
>       record
>          case Pixel_Type is
>             when Index_1 | Index_4 | Index_8 =>
>                Indexed_Order : Bitmap_Pixel_Order;
>
>             when Packed_8 | Packed_16 | Packed_32 =>
>                Packed_Order  : Packed_Component_Order;
>
>             when Array_U8 | Array_U16 | Array_U32 | Array_F16 | Array_F32 =>
>                Array_Order   : Array_Component_Order;
>
>             when others =>
>                null;
>          end case;
>       end record with
>         Unchecked_Union => True,
>         Convention      => C,
>         Size            => 4;
>
>    for Pixel_Orders use
>       record
>          Indexed_Order at 0 range 0 .. 2;
>          Packed_Order  at 0 range 0 .. 3;
>          Array_Order   at 0 range 0 .. 3;
>       end record;

> So, is this correct behaviour?

Your original version says there is one bit that is unspecified for
Pixel_Type in Index_1 | Index_4 | Index_8, so yes, this is correct
behavior.

Another way to handle the extra bit is:

          case Pixel_Type is
             when Index_1 | Index_4 | Index_8 =>
                Indexed_Order : Bitmap_Pixel_Order;
                Spare_1 : Boolean;

>If so, is there a compiler flag to catch this?

Consulting the secret documentation:

(info "(gnat_ugn) Warning Message Control")
C-s record

turns up "-gnatw.h (holes in record layouts)"

--
-- Stephe