From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM
	autolearn=unavailable autolearn_force=no version=3.4.4
X-Received: by 10.67.11.5 with SMTP id ee5mr15431498pad.12.1422840589464;
        Sun, 01 Feb 2015 17:29:49 -0800 (PST)
X-Received: by 10.140.91.21 with SMTP id y21mr189597qgd.8.1422840589388; Sun,
 01 Feb 2015 17:29:49 -0800 (PST)
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!hl2no7026348igb.0!news-out.google.com!q4ni26qan.0!nntp.google.com!bm13no5042445qab.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Sun, 1 Feb 2015 17:29:49 -0800 (PST)
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=94.7.104.90;
 posting-account=L2-UcQkAAAAfd_BqbeNHs3XeM0jTXloS
NNTP-Posting-Host: 94.7.104.90
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <49494faf-1e2d-43a1-a2b0-fd25af3850cc@googlegroups.com>
Subject: What shoudl GNAT do wrt variant record and representation clauses?
From: Lucretia <laguest9000@googlemail.com>
Injection-Date: Mon, 02 Feb 2015 01:29:49 +0000
Content-Type: text/plain; charset=ISO-8859-1
Xref: news.eternal-september.org comp.lang.ada:24840
Date: 2015-02-01T17:29:49-08:00
List-Id: <comp.lang.ada>

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.