CVS difference for ai05s/ai05-0144-2.txt
--- ai05s/ai05-0144-2.txt 2010/04/13 02:50:50 1.6
+++ ai05s/ai05-0144-2.txt 2010/04/24 05:59:35 1.7
@@ -1,5 +1,6 @@
-!standard 6.02 (11) 10-04-12 AI05-0144-2/04
+!standard 6.02 (11) 10-04-23 AI05-0144-2/05
!class Amendment 09-06-07
+!status Amendment 2012 10-04-23
!status ARG Approved 5-0-4 10-02-26
!status work item 09-06-07
!status received 09-06-07
@@ -35,10 +36,6 @@
!wording
-[I don't know where best to put this, perhaps in 6.4? - RLB]
-[We talk about access paths in 6.2, parameter modes, so that would seem to
- be a good place to discuss this related issue. -- STT]
-
Add after 6.2(11):
Two names or prefixes, N1 and N2, are *known to denote the same object* if:
@@ -46,8 +43,11 @@
* N1 statically denotes a part of a stand-alone object or parameter, and
N2 statically denotes the same part of the same stand-alone object or
parameter; or
- [We're assuming that this bullet covers selected_components, as
- those are always known at compile-time - ED]
+
+ * N1 is a selected_component P1.C1 that represents a component, N2 is a
+ selected_component P2.C2 that represents a component, selectors C1
+ and C2 are the same, and prefixes P1 and P2 are known to denote the
+ same object; or
* N1 is a dereference (implicit or explicit) of P1, N2 is a dereference
(implicit or explicit) of P2, and prefixes P1 and P2 are known to denote
@@ -59,18 +59,39 @@
static expressions with the same value, or I1 and I2 are names that
are known to denote the same object; or
- * N1 is a slice P1(S1), N2 is a slice P2(S2), the prefixes P1 and P2 are
- known to denote the same object, and the subtypes denoted by S1 and S2
- statically match.
+ * N1 and N2 are slices, their prefixes are known to denote the
+ same object, and the two slices have statically matching
+ index constraints; or
+
+ * N2 is a slice whose prefix is known to denote the same object as N1, and
+ the index constraint of N2 statically matches the constraint
+ N1'First .. N1'Last; or
+
+ * N1 is a slice whose prefix is known to denote the same object as N2, and
+ the index constraint of N1 statically matches the constraint
+ N2'First .. N2'Last.
AARM Discussion: Whether or not names or prefixes are known to denote the
same object is determined statically. If the name contains some dynamic
portion other than a dereference, indexed_component, or
- slice, it is not "known to denote the same object". [We could also
- use the same rules for indexes for the bounds of slices that have
- explicit bounds, although it doesn't seem very likely to occur and
- the wording is messy.]
+ slice, it is not "known to denote the same object".
+
+ These rules make no attempt to handle overlapping slices or slices constrained
+ for objects that are known to denote the same object.
+ These rules are intended to be symmetric: if A is known to denote the same object
+ as B, then reverse is also true.
+ End AARM Discussion.
+
+For the purpose of evaluating these rules, if N denotes a visible renaming of name R,
+R shall be used in the rules instead of N.
+
+ AARM Reason: This exposes known renamings of slices, indexing, and the like to this
+ definition. In particular, if we have
+ C : Character renames S(1);
+ then C and S(1) are known to denote the same object, as S(1) would replace C when
+ evaluating the rules.
+
Two names N1 and N2 are *known to refer to the same object* if N1 and N2
are known to denote the same object, or if N1 is known to denote a
subcomponent of the object denoted by N2, or vice-versa.
@@ -82,13 +103,6 @@
dereference changes the object in question. (There is nothing shared
between an access value and the object it designates.)
-A type is *known to be passed by reference* if it is tagged or
-immutably limited (see 7.5).
-
-AARM Reason: The by-reference property breaks privacy by requiring information
-about the full definition of partial views; these properties do not depend
-on the full definition of partial views.
-
If a call C has two or more parameters of mode in out or out that
are of an elementary type, then the call is legal only if:
@@ -129,12 +143,6 @@
AARM Ramification: We do not check expressions that are evaluated only because
of a component initialized by default in an aggregate (via <>).
-[Editor's note: I'm a bit dubious about these default_expression rules. These
-expressions are not visible to the programmer and may not actually modifiable
-by them. OTOH, it isn't very likely that they would cause a problem. These
-additional rules were suggested by the minutes of the Brest meeting, so
-they were added here.]
-
AARM Reason: These rules prevent obvious cases of dependence on the order of
evaluation of names or expressions. Such dependence is usually a bug, and
in any case, is not portable to another implementation (or even another
@@ -395,7 +403,8 @@
Since whether Var contains 4 or 6 after the call to Do_It depends on the compiler
version, optimization settings, and potentially the phase of the moon, depending
on code like this is just a ticking time bomb. So this check will mostly detect
-bugs.
+bugs. (Checks against existing code bases showed very few instances of this
+incompatibility, and most were undetected bugs.)
This rule only applies parameters that are certain to be passed by copy.
Parameters that are passed by reference have a defined semantics and are not
@@ -418,7 +427,7 @@
This would also violate our known-to-be dubious rule. Such access parameters are
problems only if they are dereferenced, and we cannot know whether the body of
the subprogram actually does that. Without such a dereference, there is no problem.
-(Of course, it is most likely that they will be dereferenced.)
+(Of course, it is likely that they will be dereferenced.)
It is annoying that the existence of that workaround is being used to make it harder
to convert to "in out" parameters in those functions (as the result might be
@@ -428,6 +437,91 @@
!example
(See discussion.)
+
+!corrigendum 6.2(11)
+
+@dinsa
+For parameters of other types, it is unspecified whether the parameter is passed
+by copy or by reference.
+@dinss
+@s8<@i<Legality Rules>>
+
+Two @fa<name>s or @fa<prefix>es, @i<N1> and @i<N2>, are @i<known to denote the
+same object> if:
+
+@xbullet<@i<N1> statically denotes a part of a stand-alone object or parameter, and
+@i<N2> statically denotes the same part of the same stand-alone object or
+parameter; or>
+
+@xbullet<@i<N1> is a @fa<selected_component> @i<P1.C1> that represents a
+component, @i<N2> is a @fa<selected_component> @i<P2.C2> that represents a
+component, @fa<prefix>es @i<P1> and @i<P2> are known to denote the same object,
+and selectors @i<C1> and @i<C2> are the same; or>
+
+@xbullet<@i<N1> is a dereference (implicit or explicit) of @i<P1>, @i<N2> is a
+dereference (implicit or explicit) of @i<P2>, and @fa<prefix>es @i<P1> and
+@i<P2> are known to denote the same object; or>
+
+@xbullet<@i<N1> is an @fa<indexed_component> @i<P1>(@i<I1>,...), @i<N2> is an
+@fa<indexed_component> @i<P2>(@i<I2>,...), the @fa<prefix> @i<P1> is known to
+denote the same object as the @fa<prefix> @i<P2>, and for each index of the
+@fa<indexed_component>, @i<I1> and @i<I2> are static expressions with the same
+value, or @i<I1> and @i<I2> are names that are known to denote the same object;
+or>
+
+@xbullet<@i<N1> and @i<N2> are @fa<slice>s, their @fa<prefix>es are known to denote
+the same object, and the two @fa<slice>s have statically matching index constraints;
+or>
+
+@xbullet<@i<N2> is a @fa<slice> whose @fa<prefix> is known to denote the same object as
+@i<N1>, and the index constraint of @i<N2> statically matches the constraint
+@i<N1>'First .. @i<N1>'Last; or>
+
+@xbullet<@i<N1> is a @fa<slice> whose @fa<prefix> is known to denote the same object as
+@i<N2>, and the index constraint of @i<N1> statically matches the constraint
+@i<N2>'First .. @i<N2>'Last.>
+
+For the purpose of evaluating these rules, if @i<N> denotes a visible renaming
+of name @i<R>, @i<R> shall be used in the rules instead of @i<N>.
+
+Two @fa<name>s @i<N1> and @i<N2> are @i<known to refer to the same object> if
+@i<N1> and @i<N2> are known to denote the same object, or if @i<N1> is known to
+denote a subcomponent of the object denoted by @i<N2>, or vice-versa.
+
+If a call @i<C> has two or more parameters of mode @b<in out> or @b<out> that
+are of an elementary type, then the call is legal only if:
+
+@xbullet<For each @fa<name> @i<N> that is passed as a parameter of mode @b<in out> or
+@b<out> to the call @i<C>, there is no other @fa<name> among the other
+parameters of mode @b<in out> or @b<out> to @i<C> that is known to denote the
+same object.>
+
+If a construct @i<C> has two or more direct constituents that are @fa<name>s or
+@fa<expression>s whose evaluation may occur in an arbitrary order, at least
+one of which contains a function call with an @b<in out> or @b<out> parameter,
+then the construct is legal only if:
+
+@xbullet<For each name @i<N> that is passed as a parameter of mode @b<in out> or
+@b<out> to some inner function call @i<C2> (not including the construct @i<C>
+itself), there is no other @fa<name> anywhere within a direct constituent of the
+construct @i<C> other than the one containing @i<C2>, that is known to refer to
+the same object.>
+
+For the purposes of checking this rule:
+
+@xbullet<For an array @fa<aggregate>, an @fa<expression> associated with a
+@fa<discrete_choice_list> that has two or more discrete choices, or that has a
+nonstatic range, is considered as two or more separate occurrences of the
+@fa<expression>;>
+
+@xbullet<For a record @fa<aggregate>:>
+@xinbull<The @fa<expression> of a @fa<record_component_association> is
+considered to occur once for each associated component; and>
+@xinbull<The @fa<default_expression> for each @fa<record_component_association>
+with <@> for which the associated component has a @fa<default_expression>
+is considered part of the @fa<aggregate>;>
+@xbullet<For a call, any @fa<default_expression> evaluated as part of the call
+is considered part of the call.>
!ACATS test
Questions? Ask the ACAA Technical Agent