CVS difference for ais/ai-00101.txt

Differences between 1.1 and version 1.2
Log of other versions for file ais/ai-00101.txt

--- ais/ai-00101.txt	1998/09/30 00:17:16	1.1
+++ ais/ai-00101.txt	1999/07/21 03:10:57	1.2
@@ -1,31 +1,32 @@
-!standard C.7.1    (03)                               96-06-05  AI95-00101/04
+!standard C.7.1    (03)                               99-07-20  AI95-00101/05
 !class binding interpretation 95-10-12
+!status Corrigendum 2000 99-05-25
 !status WG9 approved 95-06-14
 !status ARG approved 11-0-0 (by letter ballot) 96-06-05
 !status ARG approved (subject to letter ballot) 9-0-1  95-11-01
 !status received 95-10-12
 !subject Abort_Task has a parameter of mode 'in'.
 
-!summary 95-10-12
+!summary
 
 Task_Identification.Abort_Task takes a parameter of mode 'in':
 
     procedure Abort_Task (T : Task_Id);
 
-!question 95-10-12
+!question
 
 C.7.1(3) shows procedure Abort_Task taking a parameter of mode 'in out'.
 Is this correct?  (No.)
 
-!recommendation 95-10-12
+!recommendation
 
 (See summary.)
 
-!wording 95-10-12
+!wording
 
 (See summary.)
 
-!discussion 95-10-12
+!discussion
 
 Abort_Task does not modify its parameter, which is a Task_ID.
 Therefore, its parameter should be of mode 'in'.
@@ -56,9 +57,21 @@
 does not make sense for Abort_Task to set its parameter to Null_Task_ID.
 Note that it is harmless to abort the same task twice -- either with an
 abort_statement, or with Abort_Task.
+
+!corrigendum C.07.01(03)
+
+@dprepl
+@xcode<@b<procedure> Abort_Task   (T : @b<in out> Task_Id);>
+@dby
+@xcode<@b<procedure> Abort_Task   (T : Task_Id);>
+
+!ACATS test
 
-!appendix 95-10-23
+A C-Test is needed to check that calls to Abort_Task work even for functions
+or constants as parameters.
 
+!appendix
+
 !section C.7.1(03)
 !subject Why does Abort_Task have an in out parameter?
 !reference RM95-C.7.1(3);6.0
@@ -95,28 +108,28 @@
 > Task_ID.  The parameter is of mode in out rather than in, even though
 > the semantics of Abort_Task given in C.7.1(9) do not indicate that the
 > procedure alters its parameter.
-> 
+>
 > As Keith Thompson pointed out to me, this makes the call
 > Abort_Task(Current_Task) illegal, so the in out mode does no good and a
 > small amount of harm.  It ought to be changed to mode in by a binding
-> interpretation. 
+> interpretation.
 > (If this were still the language-design stage, I would
 > also suggest giving the parameter the default-value expression
 > Current_Task.)
 
-This is clearly a bug, but I'd rather have the semantics of the parameter 
-upon return changed (to its original, mistakenly dropped, intent) as opposed 
-to making it an IN only parameter.  The parameter should be Null_Task_Id 
-upon return to prevent the object from being used again for other operations 
-requiring Task_Id.  This is similar to other destroy/free operations and 
+This is clearly a bug, but I'd rather have the semantics of the parameter
+upon return changed (to its original, mistakenly dropped, intent) as opposed
+to making it an IN only parameter.  The parameter should be Null_Task_Id
+upon return to prevent the object from being used again for other operations
+requiring Task_Id.  This is similar to other destroy/free operations and
 seems to be the desired semantics.
 
-It is true that in this way, one cannot call it directly for the result of 
-Current_Task, but I don't think that this is often the need (I definitely 
-would not recommed having teh default be Current_Task, a bug here will get 
-totally undetected which would be unfriendly.  Aborting a task should not be 
-"easy", you should be required to specify which task you want to abort, even 
-if it costs you typing several more characters :-).  When aborting self is 
+It is true that in this way, one cannot call it directly for the result of
+Current_Task, but I don't think that this is often the need (I definitely
+would not recommed having teh default be Current_Task, a bug here will get
+totally undetected which would be unfriendly.  Aborting a task should not be
+"easy", you should be required to specify which task you want to abort, even
+if it costs you typing several more characters :-).  When aborting self is
 needed, one can use a local variable to store the Task_Id value od self.
 
 Offer Pazy
@@ -160,11 +173,11 @@
 
 Offer Pazy writes:
 
-| ... I'd rather have the semantics of the parameter 
-| upon return changed (to its original, mistakenly dropped, intent) as opposed 
-| to making it an IN only parameter.  The parameter should be Null_Task_Id 
-| upon return to prevent the object from being used again for other operations 
-| requiring Task_Id.  This is similar to other destroy/free operations and 
+| ... I'd rather have the semantics of the parameter
+| upon return changed (to its original, mistakenly dropped, intent) as opposed
+| to making it an IN only parameter.  The parameter should be Null_Task_Id
+| upon return to prevent the object from being used again for other operations
+| requiring Task_Id.  This is similar to other destroy/free operations and
 | seems to be the desired semantics.
 
 The situation is not exactly analogous to unchecked deallocation.
@@ -333,7 +346,7 @@
    | abort_statement for the task identified by T."
 
   > Fine.
-  
+
     Agreed. ;-)
 
    |    RM95 C.7.1(18): "If a value of Task_ID is passed as a parameter to
@@ -483,31 +496,31 @@
 !reference 95-5347.a Offer Pazy 95-10-16>>
 !discussion
 
-I still like the idea of Abort_Task returning Null_Task_Id, but the 
-arguments presented by Ted are completely correct, so maybe the right 
-solution is changing the formal to "in". There are many (legitimate and 
+I still like the idea of Abort_Task returning Null_Task_Id, but the
+arguments presented by Ted are completely correct, so maybe the right
+solution is changing the formal to "in". There are many (legitimate and
 intentional) way to interact with an abnormal task (as Ted pointed out).
-The "interaction" word at the introduction is totally non-normative.  Of 
-course you can, even fo rrendezvous, but then you get Tasking_error.  It 
-does not mean that the task does not exist or that the implementation is 
+The "interaction" word at the introduction is totally non-normative.  Of
+course you can, even fo rrendezvous, but then you get Tasking_error.  It
+does not mean that the task does not exist or that the implementation is
 allowed to not support this.  The name (and the task-id) of the task exist
-until it goes out of scope or unchecked deallocated (even in Ada 83 you 
-could do 'Terminated or 'callable on such tasks. In fact, in several places 
+until it goes out of scope or unchecked deallocated (even in Ada 83 you
+could do 'Terminated or 'callable on such tasks. In fact, in several places
 in the annexes, we have made special arrangements to allow user to refer
-*safely* to abnormal but not yet terminated tasks (attribute, dynamic 
-priorities!, Hold, etc.), so let's not confuse the issues, there is nothing 
-impl-defined here. And it has nothing to do with abort deferred regions 
-either, there is a time period between when the task becomes abnormal and 
-when it is terminated.  This window may be visible on multi processors, and 
-the semantics make it sage to refer to such a task, since tasking error will 
+*safely* to abnormal but not yet terminated tasks (attribute, dynamic
+priorities!, Hold, etc.), so let's not confuse the issues, there is nothing
+impl-defined here. And it has nothing to do with abort deferred regions
+either, there is a time period between when the task becomes abnormal and
+when it is terminated.  This window may be visible on multi processors, and
+the semantics make it sage to refer to such a task, since tasking error will
 be raised, if you did it a bit too late.
 
-So there is no problem here and let's go back to the original issue. I have 
-stated my prefernces, but I can see the other points too, so I don't feel 
-strongly either way anymore.  But please, please, please (Bevakasha Norm), 
-let's not have the default be Curernt_Task.  It is very strange that the 
-default if you do something wrong would be a suicide (also difficult to 
-debug).  It is true that more and more state adopt the capital punishment, 
+So there is no problem here and let's go back to the original issue. I have
+stated my prefernces, but I can see the other points too, so I don't feel
+strongly either way anymore.  But please, please, please (Bevakasha Norm),
+let's not have the default be Curernt_Task.  It is very strange that the
+default if you do something wrong would be a suicide (also difficult to
+debug).  It is true that more and more state adopt the capital punishment,
 but even there it applies only if you succeed, not if you "fail".
 
 
@@ -540,7 +553,7 @@
 non-erroneous cases where T'Terminated, T'Callable, Is_Terminated, and
 Is_Callable can be used with an aborted task.  However 13.9.1(8) seems
 very draconian:
-   
+
    RM 13.9.1(8): "It is erroneous to evaluate a primary that is a name
 denoting an abnormal object, or to evaluate a prefix that denotes an
 abnormal object."
@@ -618,16 +631,16 @@
 > non-erroneous cases where T'Terminated, T'Callable, Is_Terminated, and
 > Is_Callable can be used with an aborted task.  However 13.9.1(8) seems
 > very draconian:
->    
+>
 >    RM 13.9.1(8): "It is erroneous to evaluate a primary that is a name
 > denoting an abnormal object, or to evaluate a prefix that denotes an
 > abnormal object."
-> 
+>
 >     I think it was only intended to apply to names involved in
 > disrupted assignments, but 13.9.1(5) specifically mentions an abort as
 > a way for an object to become abnormal, and 9.8(1) is much more
 > explicit:
-> 
+>
 >    RM 9.8(4): "Each named task is then aborted, which consists of
 > making the task abnormal and aborting the execution of the
 > corresponding task_body unless it is already completed."
@@ -638,13 +651,13 @@
 meanings were always completely separated in my mind.
 
 Now I see that using "abnormal" for objects resulting from a disrupted
-assignment was a very unfortunate choice of terms.  This use of 
-"abnormal" has nothing whatsoever to do with the state of a task 
-called "abnormal."  
-
-Probably at this point, the simpler "fix" is to change all uses 
-of the term "abnormal" relating to a task to be simply "uncallable."  
-This is really the only guaranteed immediate affect of aborting 
+assignment was a very unfortunate choice of terms.  This use of
+"abnormal" has nothing whatsoever to do with the state of a task
+called "abnormal."
+
+Probably at this point, the simpler "fix" is to change all uses
+of the term "abnormal" relating to a task to be simply "uncallable."
+This is really the only guaranteed immediate affect of aborting
 a task -- rendering the task uncallable.
 
 Aborting a task has no effect on the task object, and certainly doesn't
@@ -652,8 +665,8 @@
 to unchecked_deallocation or leaving the scope where the task object
 is declared.  You can test 'Callable and 'Terminated completely
 safely after aborting a task; you can refer to the discriminants of the
-task object; you can ask the 'Size or the 'Address of the task object.  
-As A. A. Milne would say, there is not even a smidgen of erroneousness 
+task object; you can ask the 'Size or the 'Address of the task object.
+As A. A. Milne would say, there is not even a smidgen of erroneousness
 about it...
 
 ... [the rest is elided due to this fundamental confusion...]
@@ -689,18 +702,18 @@
 said, I think we can't clean up this one without a binding interpretation.
 
    > Now I see that using "abnormal" for objects resulting from a disrupted
-   > assignment was a very unfortunate choice of terms.  This use of 
-   > "abnormal" has nothing whatsoever to do with the state of a task 
-   > called "abnormal."  
+   > assignment was a very unfortunate choice of terms.  This use of
+   > "abnormal" has nothing whatsoever to do with the state of a task
+   > called "abnormal."
 
    I wish it were that easy to bell the cat.  It is clear that
 aborting a task can make tasks objects abnormal in the 13.9.1 sense.
 The right cure is probably to keep both uses of abnormal, and
 distinguish between an abnormal task object and an abnormal task.
 
-   > Probably at this point, the simpler "fix" is to change all uses 
-   > of the term "abnormal" relating to a task to be simply "uncallable."  
-   > This is really the only guaranteed immediate affect of aborting 
+   > Probably at this point, the simpler "fix" is to change all uses
+   > of the term "abnormal" relating to a task to be simply "uncallable."
+   > This is really the only guaranteed immediate affect of aborting
    > a task -- rendering the task uncallable.
 
      No.  Aborting a task can interrupt an assignment which is not
@@ -824,15 +837,15 @@
 !reference 95-5352.a Offer Pazy 95-10-18>>
 !discussion
 
-There is nothing ic common (I hope) between abnormal tasks and abnormal 
+There is nothing ic common (I hope) between abnormal tasks and abnormal
 objects.  If we did not screw up in CH 9 C and D, the discussion is always
-about *abnormal tasks* and not *abnormal task objects* and this is the 
+about *abnormal tasks* and not *abnormal task objects* and this is the
 difference that make you analysis inapplicable (again, I hope).
-If you could assign task objects and then the assignment would abort, then 
-the task object would become abnormal, not the task itself. So personally, I 
+If you could assign task objects and then the assignment would abort, then
+the task object would become abnormal, not the task itself. So personally, I
 don't see and need for binding interpretation or any other clarification.
 
-To emphasize, it is perfectly OK (and meaningful) to use the attributes and 
+To emphasize, it is perfectly OK (and meaningful) to use the attributes and
 the operations in Task_Identificatio on abnormal tasks.
 
 
@@ -920,9 +933,9 @@
 
   Offer Pazy said:
 
-  > There is nothing ic common (I hope) between abnormal tasks and abnormal 
+  > There is nothing ic common (I hope) between abnormal tasks and abnormal
   > objects.  If we did not screw up in CH 9 C and D, the discussion is always
-  > about *abnormal tasks* and not *abnormal task objects* and this is the 
+  > about *abnormal tasks* and not *abnormal task objects* and this is the
   > difference that make you analysis inapplicable (again, I hope).
 
    I agree that we need to distinguish between tasks in an abnormal
@@ -1089,7 +1102,7 @@
    I'm sorry, I just regard this as a minor "easy" AI that must be a
 binding interpretation because the words that would make it a
 ramification are nowhere to be found--or not to be found in the Ada 95
-RM.  The sentences I would like to quote ARE in the Ada 83 RM: 
+RM.  The sentences I would like to quote ARE in the Ada 83 RM:
 
    RM83 9.2(2): "A task object is an object whose type is a task type.
 The value of a task object designates a task that has entries of the

Questions? Ask the ACAA Technical Agent