Print

Print


> From: [log in to unmask] [mailto:[log in to unmask]]
>
> The point was that the LRM said that one of the steps of an assignment is
> to check the right-hand value against the constraints of the left-hand
> subtype.

True, *but*... (just like Pee Wee Herman said, "'but', 'but', everybody's
got a big 'but'... let's talk about your big 'but'" :-)... the effect of [RM
13.9.1(9)] is that every statement in the RM that mentions evaluating the
value of an object has an implicit "assuming the object's representation is
valid" tacked onto it.

> The vendor traced the value back to the fact that it entered this program
> by unchecked conversion from an interface.  And then said, "Not our
> problem."

The vendor may have done this "tracing" exercise themselves to excuse
themselves under the language rules , but it's something altogether
different to say that the *compiler* was supposed to be doing kind of proof
exercise in order to "optimize away" a check, where that proof exercise
involves the information flow from the result of an unchecked conversion
(I'm gathering that you were positing something like this, from something
you said in the previous post, along with the compilation-order scenario you
gave (below)).

I would think that such a proof would be in the other direction: so that a
"frendly" compiler would *avoid* optimizing away a check in the case of an
uninitialized variable.  What I suppose rather happened is that the vendor
was fully entitled to optimize away a check in the first place, for reasons
having nothing to do with Unchecked_Conversion.  So in order to satisfy the
customer that they weren't generating bogus code, they showed that the
out-of-range thing was in fact the result of an unchecked conversion.

> Somebody should have applied a legality check on
> receipt.

Problematic in Ada83 since there was no 'Valid...

> (The theory was, the other side is Ada, so it's
> impossible for it
> to be out of range.  Obviously, it was possible cause it happened.)

:-) :-) :-) :-)

> My contention is that it should be illegal for the compiler to do such an
> optimization.

To clarify: are you objecting to the language rules, or to the vendor's
interpretation of them?

> To simplify the situation,  let's reduce it to two
> packages,
> X and Y.
>
> Put all the same source code in two libraries.  In one library, compile
> spec X, spec Y, body Y, body X, then link.  In the other, compile spex X,
> body X, spec Y, body Y, then link.  Is it legal for the two programs
> (absent tasking) to have different behavior with the same inputs?

Well, that certainly *is* legal ("conforming", actually :-) if the program
is erroneous!

But maybe I'm missing your point, because I don't understand the connection
between this compilation order scenario and the question of what checks are
and are not required.  It seems like 13.9.1(9) is the last word on what the
implementation is and isn't allowed to assume about the result of an
Unchecked_Conversion...

Best,
Mark