Re: Memory overwrite?

[stt@henning.camb.inmet.com (Tucker Taft)]

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:
>
>[original post and a reply deleted]
>
>: Actually the most likely reason for this is an uninitialized variable used
>: as an array index.  In Ada 83 the following code fragment can write anywhere
>: in memory and may well not raise an exception:
>
>: declare
>: 	subtype index is integer range 1..10;
>: 	type table is array (index) of integer;
>: 	a: table;
>: 	i: index;
>: begin
>: 	a(i) := 0;
>: end;
>
>: An aggressive optimizer will eliminate any checks from the above code.
>: Even putting an explisit if statement around it doesn't help:
>
>OK, I can see how an optimiser *could* do that, and, of course, RM9x
>section 3.3.1 says that 'There is no implicit initial value defined
>for a scalar subtype ... might have a value which does not belong to
>that subtype' (para 21). I'm a little suprised, however, that the
>compiler isn't expected to perform a simple data flow analysis and
>generate a warning about use of uninitialised variables. You're quite
>right though, I can't find anything in RM9x which says it should, and
>I'm pretty sure there was nothing in the Ada83 LRM.

Actually, the words in RM95 are explicitly designed to require
that the optimizer *not* assume an uninitialized variable is
in range.  In Ada 83, an optimizer was allowed to assume
that uninitialized variables were within their declared subtype,
resulting in possible erroneous execution via wild stores.
Because an Ada 95 optimizer is required to recognize the
case when a scalar variable might be uninitialized, it seems
likely that such an optimizer will be in a good position
to produce a warning.

> ...
>
>: Ada95 add the 'valid attribute to handle this problem.
>
>Yes, this is a good idea. In another thread I've been gently pushing
>the notion that use of Ada does not eliminate the use of good SWE principles.
>It looks like you've found another example of where the sort of error
>that other languages are always being blamed for can occur in Ada.

No, actually in Ada 95, an uninitialized variable cannot lead
to erroneous execution.  If the variable has a "wild" value
in it, the run-time is required to raise a Constraint_Error.
If you are unlucky enough for the uninitialized variable to have
a reasonable in-range value, then the run-time need not complain.

>: Mark Biggar
>: mab@wdl.lroal.com
>
>Bill Williams

-Tucker Taft  stt@inmet.com
Intermetrics, Inc.
Cambridge, MA  02138