From: Nick Williams <nickw@acm.org>
Subject: Re: Help with Atomic_Components and whole array assignment
Date: Wed, 07 Feb 2001 21:40:41 +0000
Date: 2001-02-07T21:40:41+00:00 [thread overview]
Message-ID: <3A81C0D9.80607@acm.org> (raw)
In-Reply-To: 3A7886A7.F1BB5513@averstar.com
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
prev parent reply other threads:[~2001-02-07 21:40 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-01-22 11:22 Help with Atomic_Components and whole array assignment r_c_chapman
2001-01-22 12:51 ` Stuart Palin
2001-01-22 14:16 ` mark_lundquist
2001-01-22 16:09 ` Pat Rogers
2001-01-22 16:29 ` Robert Dewar
2001-01-22 19:52 ` Mark Lundquist
2001-01-30 15:54 ` Tucker Taft
2001-01-30 18:20 ` Robert Dewar
2001-01-31 5:08 ` DuckE
2001-01-31 5:57 ` Robert Dewar
2001-02-01 3:31 ` DuckE
2001-02-02 21:38 ` Mark Lundquist
2001-02-02 23:08 ` Robert Dewar
2001-02-03 1:39 ` tmoran
2001-01-22 16:21 ` Robert Dewar
2001-01-22 16:39 ` r_c_chapman
2001-01-30 15:57 ` Tucker Taft
2001-01-30 18:26 ` Robert Dewar
2001-01-30 21:30 ` Simon Wright
2001-02-01 6:11 ` Robert Dewar
2001-02-06 0:32 ` Richard Kenner
2001-02-06 3:15 ` Robert Dewar
2001-01-31 10:09 ` Rod Chapman
2001-01-31 21:41 ` Tucker Taft
2001-02-01 5:33 ` Robert Dewar
2001-02-01 9:42 ` Rod Chapman
2001-02-01 18:10 ` Robert Dewar
2001-02-01 13:14 ` SPARK flow analysis (was Help with Atomic_Components and whole array assignment) Stuart Palin
2001-02-01 23:38 ` Help with Atomic_Components and whole array assignment Nick Roberts
2001-02-02 3:45 ` Robert Dewar
2001-02-07 21:40 ` Nick Williams [this message]
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox