From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,c840deaa6965e67a
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 1995-01-18 10:20:39 PST
Newsgroups: comp.lang.ada
Path: 
 nntp.gmd.de!Germany.EU.net!EU.net!howland.reston.ans.net!usc!elroy.jpl.nasa.gov!decwrl!enews.sgi.com!wdl1!dst17!mab
From: mab@dst17.wdl.loral.com (Mark A Biggar)
Subject: Re: Memory overwrite?
Message-ID: <1995Jan18.182039.7324@wdl.loral.com>
Sender: news@wdl.loral.com
Organization: Loral Western Development Labs
References: <2093@ictser.UUCP> <3fe5cp$fnq@theopolis.orl.mmc.com>
Date: Wed, 18 Jan 1995 18:20:39 GMT
Date: 1995-01-18T18:20:39+00:00
List-Id: <comp.lang.ada>

In article <3fe5cp$fnq@theopolis.orl.mmc.com> "Theodore E. Dennison" <dennison@escmail.mmc.orl.com> writes:
>wouters@ict.nl (Rick Wouters) wrote:
>> 	An Ada program which compiles correctly and which does not produce
>> 	run-time errors seems to overwrite memory.
>> 	No dynamic allocation is used nor are address types used.
>> 	Some records are defined with a length clause.
>> 	Does anyone know a reason which might result in overwriting memory
>> 	in a correctly compiled program?
>Tons. Most of the time when this happens it is because someone 
>screwed up a "for use at" clause or an "UNCHECKED_CONVERSION" from
>System.ADDRESS.

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:

	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.

Ada95 add the 'valid attribute to handle this problem.

--
Mark Biggar
mab@wdl.lroal.com