> From: W. Wesley Groleau x4923
>
> Just curious.  Long, long ago, in a company far, far away,
> we were NOT getting constraint error that we thought we
> should at an assignment statement.
>
> The vendor's argument was that if you traced back the origin of the right
> side far enough, you'd find an unchecked conversion, therefore no checks
> were necessary.
>
> Our argument was that the compiler could not trace back that far, since
> that would require all the bodies to be compiled at the same time as the
> specs, therefore the compiler had no business skipping checks at the
> various calls along the way.
>
> Opinions?  (not that it matters now)

Hi Wes,

It's a little hard to judge without being able to see the code in question,
but ASSUMING it's something like the John McCabe's example...

My opinion would be that you were both right, I mean wrong, I mean... half
right/wrong :-) :-)

I think it's easy to get confused between range constraints (of a subtype)
and validity (of a "representation", i.e. the bit pattern), because both
concepts entail the idea of something being "out of range"... nevertheless,
they're two different concepts.

The vendor's argument (if what you're relating is indeed what they meant)
was bogus, it has nothing to do with "tracing back" anything.  But on the
other hand, it is not a matter of "skipping checks", either.  Still assuming
this was a case such as exemplified in the John's question, there's no
language-required check, so it's not really "skipping" anything.  Since both
the target of the assignment and the expression are of the same subtype,
there is no range check to perform (this is one of the really cool things
about Ada's subtype system, IMHO).  The vendor let you suck him in to the
Unchecked_Conversion irrelevancy :-)  He should have stuck to talking about
subtypes :-)

Now suppose, using John McCabe's example, we were to write:

        subtype Spring_Month is Month_Type range March .. May;

        -- The unchecked conversion (I can't remember the original name cuz
        -- I deleted the mail) and an assignment:
        --
        Happy : Spring_Month := To_Month_Type (Whatever);

In that example, the assignment *does* have to do a range check.

But here's the kicker... if the representation of the result of the
unchecked conversion is invalid, the language rules do not guarantee that
the above range check will fail!  The language doesn't tell the
implementation how to perform the check, it only specifies what a range
check means (for valid representations).  The range check is an evaluation
of the value of the object, so in the case of invalid bits we are still
under the rule of 13.9.1(9) -- that is, it's erroneous.

Mark Lundquist
Rational Software