CVS difference for ais/ai-00104.txt
--- ais/ai-00104.txt 1998/09/30 00:17:17 1.1
+++ ais/ai-00104.txt 1999/07/08 17:25:14 1.2
@@ -1,5 +1,6 @@
-!standard E.3 (04) 97-11-14 AI95-00104/06
+!standard E.3 (04) 99-07-07 AI95-00104/07
!class binding interpretation 95-10-21
+!status Corrigendum 2000 99-05-25
!status WG9 Approved 97-11-14
!status ARG approved 8-0-1 (subject to editorial review) 97-04-11
!status ARG approved 12-0-0 (subject to editorial review) 96-10-07
@@ -11,7 +12,7 @@
!subject Version and Body_Version attributes
If P is not a library unit, and P has no completion, then P'Body_Version
returns the Body_Version of the innermost program unit enclosing the
@@ -28,7 +29,7 @@
also unspecified whether there are other events (such as recompilation)
that result in the version of a compilation unit changing.
@@ -57,15 +58,15 @@
would return a different value every time, which would make them
useless. What is the intent?
It should not be an error to query P'Body_Version when P has no body,
@@ -158,8 +159,38 @@
Note that if X is a renaming declaration (not a renaming-as-body), then
X'Version and X'Body_Version refer to the versions of the renamed
+The @i<version> of a compilation unit changes whenever the version changes
+for any compilation unit on which it depends semantically. The version also
+changes whenever the compilation unit itself changes in a semantically
+significant way. It is implementation defined whether there are other events
+(such as recompilation) that result in the version of a compilation unit
+The @i<version> of a compilation unit changes whenever the compilation unit
+changes in a semantically significant way. This International Standard
+does not define the exact meaning of "semantically significant". It is
+also unspecified whether there are other events (such as recompilation)
+that result in the version of a compilation unit changing.
+If P is not a library unit, and P has no completion, then P'Body_Version
+returns the Body_Version of the innermost program unit enclosing the
+declaration of P. If P is a library unit, and P has no completion,
+then P'Body_Version returns a value that is different from Body_Version
+of any version of P that has a completion.
+A useful test of these attributes is difficult to construct. Probably the
+most useful test would be a pair of C-Tests which check that the version
+values change when a "semantically significant" change is made. There is
+not currently an ACATS test checking this.
!subject P'Body_Version for package with no body
@@ -1012,7 +1043,7 @@
> built on different systems at different times; then how do you make
> sure that the partition you are calling did use the same spec than the
> one you used at compilation time?
> In our case, versions are used to ensure that we have a global
> consistency. Since we have several executables which may have been
> bound and linked separately from each other, we cannot rely on a
@@ -1027,7 +1058,7 @@
> Offer> P.S. I wonder if 'Partition_Version would not have been a much
> Offer> more useful and simpler solution...
> I don't think so for the reasons explained above: we need a per
> package information, since we don't know a priori what will reside in
> a partition (and in our model, we don't even know at compile time
@@ -1042,10 +1073,10 @@
> Let's say that Compression_Method is a normal unit (replicated
> on two partitions P1 with RCI_1 and P2 with RCI_2) with the
-> same specification on both sides.
+> same specification on both sides.
> On RCI_1
> if Compression_Method'Body_Version =
> RCI_2.Get_Your_Compression_Body_Version then
@@ -1066,8 +1097,8 @@
> Don't except too much from the partitioning/configuration
> tool. Version consistency checks have to be performed during
-> execution. Otherwise, they are useless.
+> execution. Otherwise, they are useless.
> If partitions are built by two different compilers vendors, first,
> they should check consistency by calling `Version; second, `Version
> has to be precisely defined such a way that the two implementations
@@ -1086,15 +1117,15 @@
hash-code on the source text (with or without comments, etc).)
> Offer Pazy wrote :
-> | It seems to me that you have to ensure that the function
-> | Get_Your_Compression_Method must always return the a value consistent with
-> | the attribute value. This may be specially tricky when the said body
-> | indirectly depends on other things in RCI_2 (just as the value of some
+> | It seems to me that you have to ensure that the function
+> | Get_Your_Compression_Method must always return the a value consistent with
+> | the attribute value. This may be specially tricky when the said body
+> | indirectly depends on other things in RCI_2 (just as the value of some
> | variable which may be set by another, completely unrelated unit, in RCI_2).
> True, so what? Compression_Method unit is different, the client is not
> sure that the server compression is *exactly* the same and will send
-> the regular image.
+> the regular image.
But, given the current definition of 'Body_Version in the RM (and in
AI-104), there is no way for the client to know that it is not *exactly*
Questions? Ask the ACAA Technical Agent