CVS difference for ais/ai-00209.txt

Differences between 1.6 and version 1.7
Log of other versions for file ais/ai-00209.txt

--- ais/ai-00209.txt	2004/04/06 19:56:57	1.6
+++ ais/ai-00209.txt	2004/05/29 00:38:33	1.7
@@ -1,4 +1,4 @@
-!standard H.3.1     (8)                             04-03-24  AI95-00209/03
+!standard H.3.1     (8)                             04-05-21  AI95-00209/04
 !standard H.3.2     (9)
 !class binding interpretation 99-02-05
 !status Amendment 200Y 04-03-24
@@ -15,12 +15,12 @@
 In H.3.1(8), the term "reference (to)" needs to be replaced by "read (of)".
 H.3.2(9) needs to be similarly changed.
 
-For the purposes of Pragma Reviewable, objects are uninitialized, if
+For the purposes of Pragma Reviewable, objects are uninitialized if
 they never were initialized or assigned to prior to use. All such
 objects must be identified by an implementation in conformance with
 H.3.1(8).
 
-An implementation may identify additional objects as uninitialized, if
+An implementation may identify additional objects as uninitialized if
 the value of an uninitialized object is assigned to them.
 
 An implementation may, but need not, take advantage of aliasing
@@ -56,7 +56,7 @@
 H.3.1(8) should read: "For each read of a scalar object, an identification
 of the read as either ....."
 
-The 2. sentence of H.3.2(9) should read: "Thus an inspection point has
+The second sentence of H.3.2(9) should read: "Thus an inspection point has
 the effect of an implicit read of each of its inspectable objects."
 
 !discussion
@@ -64,7 +64,7 @@
 First, the term "reference" in H.3.1(8) is incorrect as it also
 includes the occurrence as the target of an assignment. Clearly, only
 reads of the object were meant to be diagnosed. Similarly,
-the NOTE H.3.2(9) in imprecise by its usage of the term "reference".
+the NOTE H.3.2(9) is imprecise by its usage of the term "reference".
 
 A definitive answer to the !question seems counter-productive. A model
 that allows for a "deinitialization" caused by assigning the value of
@@ -90,12 +90,13 @@
 assigned the object's value. However, if the compiler diagnostics
 assume transitive infection, then these other variables will
 (continue to) be diagnosed as uninitialized, misleading the user.
+
 Consider:
   if P then X := 7; end if;
   ...
   if Q then Y := X; else Y := 6; end if;
   A := Y;
-  B:= A + 1;
+  B := A + 1;
 
 Assume further that Q implies P. Of course, Y is then well defined
 under all circumstances. However, the transitive infection model would
@@ -143,15 +144,15 @@
 !corrigendum H.3.2(9)
 
 @drepl
-The implementation is not allowed to perform ``dead store elimination'' on
+@xindent<@s9<7  The implementation is not allowed to perform ``dead store elimination'' on
 the last assignment to a variable prior to a point where the variable is
 inspectable. Thus an inspection point has the effect of an implicit reference
-to each of its inspectable objects.
+to each of its inspectable objects.>>
 @dby
-The implementation is not allowed to perform ``dead store elimination'' on
+@xindent<@s9<7  The implementation is not allowed to perform ``dead store elimination'' on
 the last assignment to a variable prior to a point where the variable is
 inspectable. Thus an inspection point has the effect of an implicit read of
-each of its inspectable objects.
+each of its inspectable objects.>>
 
 !ACATS Test
 

Questions? Ask the ACAA Technical Agent