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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,cbd507df3efa824b
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2001-02-07 13:41:05 PST
Path: 
 supernews.google.com!sn-xit-02!supernews.com!isdnet!grolier!btnet-peer0!btnet-feed5!btnet!mendelevium.btinternet.com!not-for-mail
From: Nick Williams <nickw@acm.org>
Newsgroups: comp.lang.ada
Subject: Re: Help with Atomic_Components and whole array assignment
Date: Wed, 07 Feb 2001 21:40:41 +0000
Organization: BT Internet
Message-ID: <3A81C0D9.80607@acm.org>
References: <94h55t$9a1$1@nnrp1.deja.com> <94hml1$o64$1@nnrp1.deja.com>
 <94hno6$p8s$1@nnrp1.deja.com> <3A76E455.AABF2490@averstar.com>
 <958o8f$vem$1@nnrp1.deja.com> <3A7886A7.F1BB5513@averstar.com>
NNTP-Posting-Host: host213-1-101-72.btinternet.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.0 i686; en-US; 0.7) Gecko/20010105
X-Accept-Language: en
Xref: supernews.google.com comp.lang.ada:4951
Date: 2001-02-07T21:40:41+00:00
List-Id: <comp.lang.ada>

Tucker Taft wrote:


>> The compound statement
>>    for I in A'Range loop
>>       A(I) := 0;
>>    end loop;
>> has information flow "derives A from A", which is significantly
>> different.

> I don't understand why this derives A from A.  Is this just
> a limitation of SPARK?  Clearly, we are assigning a new
> value to every component of A, making no use of the original
> values.

Well, yes; clearly, it is simple to prove that this loop assigns new 
values to every element of A, but in terms of information flow (as 
defined by Bergeretti and Carre, and as implemented in the SPARK 
Examiner) it 'derives A from A'.

The central intuition derives from the first iteration through the loop 
- in this case, the new value of A is derived from a constant loop 
range, a literal constant and A itself (since only one element has changed).

The limitation is that array elements are not 'first class' from the 
perspective of the flow analyser - even if this were theoretically 
viable, the practicalities of tracking flow relations for a ten million 
element array would, I suspect, be prohibitive.

However - as I understand it - it's not even technically useful to 
promote array elements in this way within the current framework; to do 
so makes flow analysis equivalent to execution:

   subtype A_Type is Integer range 1 .. 1000;
   type An_Array is array A_Type of Integer;

   A : An_Array;
   X : A_Type;
   function Complicated_Function returns A_Type;
   function Another_Complicated_Function returns Integer;

   ...

   X := Complicated_Function;
   A(X) := Another_Complicated_Function;

Without actually calculating X, all that can be said is that any given 
element of A might potentially be assigned to by the above statements. 
However it equally well might not, and (as such) for all relevant I, 
A(I) would be derived from A(I), and whatever variables are used in the 
derivation of the result of Another_Complicated_Function.

Although I'm sure there are some simple cases where performing flow 
analysis at the array element level gives more intuitively 'correct' 
analyses, I'm minded to think that it probably would not be a very 
useful addition - I'm sure Peter or Rod will pick me up if they disagree!

Cheers,

Nick
PxCS