CVS difference for ai05s/ai05-0113-1.txt

--- ai05s/ai05-0113-1.txt	2008/10/07 01:56:22	1.1
+++ ai05s/ai05-0113-1.txt	2008/10/25 04:53:14	1.2
@@ -1,5 +1,6 @@
-!standard 3.9(12.1/2)                                         08-10-06  AI05-0113-1/01
+!standard 3.9(12.1/2)                                         08-10-06  AI05-0113-1/02
 !standard 3.9(25.3/2)
+!standard 3.9(26.1/2)
 !standard 13.3(76)
 !class binding interpretation 08-10-06
 !status work item 08-10-06
@@ -7,17 +8,27 @@
 !priority Low
 !difficulty Easy
 !qualifier Omission
-!subject Conflicting external tags
+!subject Conflicting external tags and other tag issues
 
 !summary
 
 If a user-specified external tag S'External_Tag is the same as T'External_Tag for some
 other type, execution of the partition is erroneous.
 
+The Implementation Advice for Internal_Tag suggests returning a tag for a type that
+beongs to some master of the call to Internal_Tag.
+
 !question
 
-If users specify values for 'External_Tags, it's possible that the external tags
-for two different type declarations may be the same, probably by accident.  
+(1) If users specify values for 'External_Tags, it's possible that the external tags
+for two different type declarations may be the same, probably by accident. What is
+returned from Tags.Internal_Tag and Tags.Descendant_Tag in that case?
+
+(2) 3.9(26/2) says that Tag_Error can be raised if there no type whose innermost
+master is a master of the point of the function call, but 3.9.(26.1/2) suggests that
+Internal_Tag return a tag of a type whose tag is *the* innermost master of the point
+of the call. But the innermost master is usually the function call itself, which
+surely does not have an innermost master. What is the intent?
 
 !recommendation
 
@@ -42,6 +53,15 @@
 be unique for this case.) This second case is the one that this rule is
 intended to catch.
 
+Modify 3.9(26.1/2) as follows:
+
+Internal_Tag should return the tag of a type whose innermost master is {a}[the]
+master of the point of the function call{, if one exists}.
+
+AARM Note: There is no Advice for the result of Internal_Tag if no such type exists.
+In most cases, the Implementation Permission can be used to raise Tag_Error, but
+some other tag can be returned as well.
+
 Add before 13.3(76):
 
 Erroneous Execution
@@ -78,6 +98,21 @@
 too). So we just need a rule for Dependent_Tag. We made it a Bounded Error
 to minimize disruption but still to allow detection.
 
+For (2), we change the wording to "a master". The original intent was that
+master of the innermost task was "the" master, but that seems wrong (it would
+mean that the return of library-level tags would not be advised, which
+seems wrong). We could try to say that a tag whose master is the innermost
+one surrounding the call that has an applicable type is returned, but that
+is hard to word (or explain) and seems like overspecification, as it not
+likely that there are multiple applicable tagged types in different masters
+surrounding the call. It is enough to say that the tag should belong to some
+master of the call, especially as the primary goal is to prevent returning
+tags of types that belong to unrelated tasks. The wording "if one exists" is
+added to make it clear that this does not specify the result in all cases.
+Note that this change has the nice effect of matching the wording of the
+Implementation Permission 3.9(26/2), so that Tag_Error can be raised if
+the Implementation Advice cannot be followed.
+
 --!corrigendum 13.3(76)
 
 !ACATS Test
@@ -167,6 +202,71 @@
 
 ****************************************************************
 
+!topic Probable wording error in 3.9(26.1)
+!reference 3.9(26.1)
+!from Adam Beneschan 08-06-13
+!discussion
+
+
+This clause reads: "Internal_Tag should return the tag of a type whose
+innermost master is the master of the point of the function call".
+                    ^^^
+
+I suspect that the word "the" right before "master" is wrong and should
+be "a".  In 3.9(26), which uses almost identical wording, the word "a"
+is used: "... or if there is no such type whose innermost master is
+a master of the point of the function call".
+^^^
+
+But the wording "*the* master of the point of the function call"
+implies that, at the point where the function call occurs, there
+is one master that would be considered "the" master of that point.
+What would it be?  It wouldn't make sense for it to be the innermost
+master, since that would in many cases be the simple_statement that
+performs the function call, or the function call itself; and that can't
+be the innermost master of the type.  Even if "the" master were the
+innermost enclosing subprogram, the Implementation Advice would still
+not be followable in a case like:
+
+   task body Task_Type_1 is
+
+      type T1 is tagged record ... end record;
+      for T1'External_Tag use "ext_T1";
+
+      procedure Inner is
+         T : Ada.Tags.Tag;
+      begin
+         T := Ada.Tags.Internal_Tag ("ext_T1");
+      end;
+
+I'm guessing that this is just a typo in 3.9(26.1).
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, June 13, 2008  8:03 PM
+
+I'm certain it is not a typo (it's just wrong). For one thing, it
+was written before statements and calls and the like became masters.
+My intent (best as I recall it) was that the advice would suggest that
+Internal_Tag to only support library-level tagged types (since it has
+no practical way to find out which nested things are safe). Thus the
+wording was written to be as restrictive as possible. But of course
+it is wrong because it doesn't take the very inner masters into
+account -- really all we want to require is the *outermost* master.
+
+The bug is that there isn't a matching permission to raise an exception,
+so it isn't clear what to do in the cases that have the wrong master
+but aren't covered by permission. That probably happened because the
+ARG made me weaken the permission, and we forgot to change the advice.
+
+So you're probably right about the needed change, (given that I don't
+think the rest of the ARG would agree to a more restrictive rule), but
+it surely isn't a typo. (It also doesn't matter much either way,
+since the wording is Implementation Advice, which can always be ignored
+if needed.)
+
+****************************************************************