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

--- ai05s/ai05-0092-1.txt	2008/07/12 03:58:22	1.4
+++ ai05s/ai05-0092-1.txt	2008/10/25 04:53:14	1.5
@@ -1,6 +1,7 @@
-!standard  3.3.1(20.4/2)                                08-07-11  AI05-0092-1/03
-!standard 3.9(25.1/2)
+!standard  3.3.1(20.4/2)                                08-10-06  AI05-0092-1/04
+!standard  3.9(25.1/2)
 !standard  6.3.1(21.1/2)
+!standard  9.6(22)
 !standard 13.3(75/1)
 !standard 13.13.2(55/2)
 !standard 13.13.2(56/2)
@@ -36,6 +37,11 @@
 
 8) Replace "Interface_Ancestor_Tag" with "Interface_Ancestor_Tags" in 3.9(25.1/2).
 
+9) The routines Wide_Expanded_Name and Wide_Wide_Expanded_Name should be listed
+in 3.9(25.1/2).
+
+10) Replace "_statement" with "statement".
+
 !question
 
 1) Generally, "must" shall not be used in normative rules of the standard. However,
@@ -58,6 +64,12 @@
 8) 3.9(25.1/2) mentions "Interface_Ancestor_Tag", but there is no such thing.
 Change to "Interface_Ancestor_Tags"? (Yes.)
 
+9) 3.9(25.1/2) mentioned "Expanded_Name", but it doesn't mention "Wide_Expanded_Name"
+and "Wide_Wide_Expanded_Name". Should it? (Yes.)
+
+10) 9.6(22) includes "_statement"; this fragment is unseemly. Should this be replaced
+by "statement"? (Yes.)
+
 [Other questions here.]
 
 !recommendation
@@ -83,6 +95,11 @@
 
 8) Replace "Interface_Ancestor_Tag" with "Interface_Ancestor_Tags" in 3.9(25.1/2).
 
+9) Replace "or Parent_Tag" with "Parent_Tag, Wide_Expanded_Name, or
+Wide_Wide_Expanded_Name" in 3.9(25.1/2).
+
+10) Replace "_statement" with "statement" in 9.6(22).
+
 !discussion
 
 1) 3.3.1(20.4/2) uses "must precede", while 3.3.1(20.1-3/2) use "is preceded by".
@@ -108,6 +125,17 @@
 
 8) An obvious missing 's'.
 
+9) The Wide and Wide_Wide versions of Expanded_Name surely should raise the same
+exceptions as the base version. Anything else would be madness. Note that the
+routines are listed in alphabetical order.
+
+10) This is one of a number of similar fragments in the Ada 95 RM. As they interfere
+with automated linking and indexing (and look like a mistake), we've been eliminating
+them when possible. We could have used the entire "delay_statement" here, but that
+would seem redundant (there are two other occurrences of delay_statement in the
+paragraph).
+
+
 !corrigendum 3.3.1(20.4/2)
 
 @drepl
@@ -133,8 +161,8 @@
 passed is No_Tag.
 @dby
 Tag_Error is raised by a call of Descendant_Tag, Expanded_Name, External_Tag,
-Interface_Ancestor_Tags, Is_Descendant_At_Same_Level, or Parent_Tag if any tag
-passed is No_Tag.
+Interface_Ancestor_Tags, Is_Descendant_At_Same_Level, Parent_Tag, Wide_Expanded_Name,
+or Wide_Wide_Expanded_Name if any tag passed is No_Tag.
 
 !corrigendum 6.3.1(21.1/2)
 
@@ -145,6 +173,20 @@
 @xbullet<each @fa<attribute_designator> in one is the same as the
 corresponding @fa<attribute_designator> in the other; and>
 
+!corrigendum 9.6(22)
+
+@drepl
+If an attempt is made to @i<cancel> the @fa<delay_statement> (as part of an
+@fa<asynchronous_select> or abort — see 9.7.4 and 9.8), the @fa<_statement>
+is cancelled if the expiration time has not yet passed, thereby completing the
+@fa<delay_statement>.
+@dby
+If an attempt is made to @i<cancel> the @fa<delay_statement> (as part of an
+@fa<asynchronous_select> or abort — see 9.7.4 and 9.8), the statement
+is cancelled if the expiration time has not yet passed, thereby completing the
+@fa<delay_statement>.
+
+
 !corrigendum 13.3(8.1/2)
 
 @drepl
@@ -580,5 +622,39 @@
 Bounded_Wide_Wide_String. 
 
 There are similar errors in A.11(5).
+
+****************************************************************
+
+!topic Wrong name, missing names in 3.9(25.1)
+!reference 3.9(25.1)
+!from Adam Beneschan 08-06-13
+!discussion
+
+3.9(25.1) lists Interface_Ancestor_Tag as one of the routines that raises
+Tag_Error if given a No_Tag argument.  But the correct name is
+Interface_Ancestor_Tags (with an "s" at the end).
+
+Also, it lists Expanded_Name, but shouldn't it also list Wide_Expanded_Name
+and Wide_Wide_Expanded_Name?
+
+****************************************************************
+
+!topic _statement
+!reference 9.6(22)
+!from Christoph Grein 2008-08-07
+!discussion
+Quote: "..., the _statement is cancelled ..."
+Is the fragment _statement intentional here? (No, I guess. This is already in RM 95.)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Saturday, August  9, 2008  12:58 AM
+
+That is quite common in the RM 95; there were many such fragments around.
+I've been trying to get rid of them when we have a reason to change a paragraph
+anyway, but it doesn't seem important enough to do in general.
+(This sort of thing made a mess for the automatic syntax link generator for the
+HTML version of the Standard.)
 
 ****************************************************************