But if the values in there do not reflect the reality of what values
are valid for the type, then I don't see how they can be generally
useful -- that's my point. We have two fields that are inaccurate,
apparently on purpose, and as a result they are basically unusable.
No, they *do* reflect the "reality of what values are valid for the type".
The only glitch, which is not what we're talking about here, is that you have
to have a way to implement the language-defined test to see if the value is
valid or not. However, the need to implement that relative-uncommon test
should't drive the basic methodology used to represent types.
With checking enabled, "normal" Ada usage should not be able to generate an
invalid value, so the assumption by VRP that the values are in the valid
range is a correct one (of course, you do have to be able to generate those
checks!). With checking disabled, an Ada program is erroneous if it
generates a value outside that range, so again VRP can assume the values are
in the specififed range.
There's only one exception here. It's valid to do a "unchecked conversion"
from arbitrary data into a value of a subtype with a restricted range. You
are then allowed to test (using 'Valid) whether or not the value is in range.
But any use of an out-of-range value (other than 'Valid) is also erroneous.
So the Ada rules and what VRP are assuming are precisely consistent. We
unfortunately have bugs in two areas. The first are not having a good way of
making sure the validity check isn't suppressed and the second is that there
apparently places where trees are being generated that do operations
improperly. These simply have to be found and fixed. I found one quite a
while ago (when folding ranges) and I'm sure there are more (somebody
speculated that perhaps fold is removing conversions that are, in fact,
needed).
