* What shoudl GNAT do wrt variant record and representation clauses?
@ 2015-02-02 1:29 Lucretia
2015-02-02 7:45 ` jsquirek
` (2 more replies)
0 siblings, 3 replies; 5+ messages in thread
From: Lucretia @ 2015-02-02 1:29 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: What shoudl GNAT do wrt variant record and representation clauses?
2015-02-02 1:29 What shoudl GNAT do wrt variant record and representation clauses? Lucretia
@ 2015-02-02 7:45 ` jsquirek
2015-02-02 7:55 ` Lucretia
2015-02-02 9:04 ` Simon Wright
2015-02-04 9:59 ` Stephen Leake
2 siblings, 1 reply; 5+ messages in thread
From: jsquirek @ 2015-02-02 7:45 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: What shoudl GNAT do wrt variant record and representation clauses?
2015-02-02 7:45 ` jsquirek
@ 2015-02-02 7:55 ` Lucretia
0 siblings, 0 replies; 5+ messages in thread
From: Lucretia @ 2015-02-02 7:55 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: What shoudl GNAT do wrt variant record and representation clauses?
2015-02-02 1:29 What shoudl GNAT do wrt variant record and representation clauses? Lucretia
2015-02-02 7:45 ` jsquirek
@ 2015-02-02 9:04 ` Simon Wright
2015-02-04 9:59 ` Stephen Leake
2 siblings, 0 replies; 5+ messages in thread
From: Simon Wright @ 2015-02-02 9:04 UTC (permalink / raw)
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)
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: What shoudl GNAT do wrt variant record and representation clauses?
2015-02-02 1:29 What shoudl GNAT do wrt variant record and representation clauses? Lucretia
2015-02-02 7:45 ` jsquirek
2015-02-02 9:04 ` Simon Wright
@ 2015-02-04 9:59 ` Stephen Leake
2 siblings, 0 replies; 5+ messages in thread
From: Stephen Leake @ 2015-02-04 9:59 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2015-02-04 9:59 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-02-02 1:29 What shoudl GNAT do wrt variant record and representation clauses? Lucretia
2015-02-02 7:45 ` jsquirek
2015-02-02 7:55 ` Lucretia
2015-02-02 9:04 ` Simon Wright
2015-02-04 9:59 ` Stephen Leake
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox