Re: Memory overwrite?

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

In article <3g2stg$i0u@miranda.gmrc.gecm.com>,
R.A.L Williams <bill@valiant> wrote:
>In article <1995Jan18.182039.7324@wdl.loral.com> Mark Biggar wrote:
>: 	if i in index then
>: 		a(i) := 0;
>: 	else
>: 		raise constraint_error;
>: 	end if;
>
>: because an aggressive optimizer will notice that the if test is always true
>: (in the absence of uninitialized variables, but uninitialized variables
>: are erroneous, which allow any behaviour, so it can ignore the problem)
>: and eliminate the test and the else branch completely.

I just want to emphasize that this is no longer true in Ada 95.  In Ada
95, the above will raise an exception if i is not in index, even if its
because i is not initialized.

>: Ada95 add the 'valid attribute to handle this problem.

Not really.  'Valid is mainly for checking data that comes from
Unchecked_Conversion, input, or from another language.  These are
isolated cases, and the programmer can use 'Valid as appropriate.

But variables occur all over the place.  It would not be feasible to put
'Valid checks all over the place, just to make sure you didn't forget to
initialize a variable.

Note the difference in these two cases: using an uninitialized variable
is a bug, and there are numerous places where it *might* happen in any
given program.  Input data, on the other hand, is not under control of
the programmer.  Bad input data is not a program bug.  And the number of
places in a program that do input is relatively small.

Again, using an uninitialized variable is *not* erroneous is Ada 95, so
if an optimizer wants to eliminate a check, it has to prove that the
check will not fail, even in the presence of uninitialized variables.

There's also a feature in the Safety and Security annex that tells the
compiler to initialize things to an out-of-range value (if it fits in
the bits of the object), to increase the likelihood that using an
uninitialized variable will cause the program to trip over a constraint
check.

- Bob