On 3/16/06, Geert Bosch <[EMAIL PROTECTED]> wrote: > > On Mar 16, 2006, at 05:09, Robert Dewar wrote: > > Not quite right. If you have an uninitialized variable, the value is > > invalid and may be out of bounds, but this is a bounded error > > situation, > > not an erroneous program. So the possible effects are definitely NOT > > unbounded, and the use of such values cannot turn a program erroneous. > > (that's an Ada 95 change, this used to be erroneous in Ada 83). > > Actually, that's a good point and raises some potential issues: > if we're never establish the invariant that a value of a type is in > range, we can only use the base range for variables that might be > used uninitialized. Any read of such a variable would then involve > a range check. > > package Uninitialized is > N : Positive; > end Uninitialized; > > with Uninitialized; > procedure Test is > for J in 1 .. Uninitialized.N loop > ... > end loop; > end Test; > > In this case, GCC might replace the loop with > declare > J : Integer := 1; > begin > while J /= Uninitialized.N loop > ... > J := J + 1; > end loop; > end; > > which would be incorrect for N = 0.
Uh - what do you expect here?? Does the Ada standard require a out-of-range exception upon the first use of N? In this case, the frontend needs to insert a proper check. You cannot expect the middle-end to avoid the above transformation, so this is a frontend bug. Richard.
