Re: Why no constraint error?

[bobduff@world.std.com (Robert A Duff)]

In article <5gs81q$114r@prime.imagin.net>,
Samuel Mize <smize@imagin.net> wrote:
>In article <5gs20s$2g11@prime.imagin.net>,
>Samuel Mize <smize@imagin.net> wrote:
>>The question is, why doesn't this code raise an exception when run
>>under GNAT?
>>
>>    pragma Normalize_Scalars;
>>    with Ada.Text_Io;
>>    procedure Test_Subrange_Checks is
>>        type T_Source  is new Integer range 7 .. 10;
>>        type T_Target is new Integer range 7 .. 10; -- identical ranges
>>
>>        Source: T_Source; -- initialized out of range by Normalize_Scalars
>>        Target: T_Target := 10;
>>    begin
>>        Target := T_Target (Source);  -- no range check occurs!!!!!!!!!!
>>        Ada.Text_Io.Put_Line (T_Target'Image (Target));
>>    end Test_Subrange_Checks;
>
>
>It turns out GNAT is right.  (No big surprise.)

No, I believe GNAT is wrong.

>I think I've found it.  13.9.1(9) defines invalid representations;
>it also states "The rules of the language outside this subclause
>assume that all objects have valid representations."
>
>So, the compiler can omit the range checks by assuming that
>the data is valid.

No, that's not what I meant when I wrote 13.9.1(9).  That is, the
compiler cannot assume data is valid.  The *rules* in the rest of the RM
assume valid data, but that assumption is wrong, and 13.9.1 tries to
fill in the resulting logical holes.

In your example, Source should be initialized to some invalid value of
type T_Source, such as 11.  13.9.1(10) applies, and 11 is greater than
10 (despite the fact that 11 is invalid), and so should fail the range
check.  I believe there is no permission to omit that check.

Unfortunately, 13.9.1(11) is a loophole you could drive a truck through.
The assumption is that compilers will be reasonable.  There's some AARM
discussion on this point.  But this para is irrelevant to your example.

I'm not entirely sure if the above analysis is correct.  Tucker, if
you're listening, can you comment?

>Note that, in a similar case, an array reference can point to
>any arbitrary memory location (uninitialized scalar used as
>an array index).

It was definitely a goal of Ada 9X that an uninitialized variable cannot
cause arbitrary memory locations to be overwritten (e.g. when you say
"A(I) := ..." and I is uninitialized.  This is true whether or not you
say Normalize_Scalars.  (In Ada 83, such a case is erroneous, and so
could trash memory or anything else bad.)

>While I understand this from an efficiency point of view, I'd
>like it to be different.  Whine, whine.  One project I'm on is
>auto-converting a huge base of occam code to Ada, and a number
>of uninitialized integers are biting us in the tail.
>(don't start, we DON'T HAVE occam on our target machine)
>
>However, I now see how this optimization is allowed by the
>formal rules, so I'll live with it.
>
>One useful compiler option, it seems to me, would tell the
>compiler to NOT omit such checks in such cases -- to do
>explicitly all range checks.  I'd love to be able to test
>some of this auto-generated garbage under such an option.

I'd like to have an option to check all uninit vars.

- Bob