CVS difference for ais/ai-00166.txt
--- ais/ai-00166.txt 1998/10/01 00:24:28 1.2
+++ ais/ai-00166.txt 1999/02/08 23:00:55 1.3
@@ -1,22 +1,23 @@
-!standard C.3.2 (18) 98-05-06 AI95-00166/02
+!standard C.3.2 (18) 99-02-05 AI95-00166/03
!class binding interpretation 96-11-16
+!status ARG-approved (7-0-0) 98-10-09
!status work item (draft by Ted Baker, per action at St. Louis meeting)
!status received 96-11-16
!subject Parameterless_Handler values designating default treatment
-When a default treatment is effect for an interrupt, the value
+When a default treatment is in effect for an interrupt, the value
returned by Current_Handler is null. Likewise, the value returned
in Old_Handler by the Exchange_Handler procedure is null if it is
invoked while the default treatment is in force for the specified
-Furthermore, the value of returned by Current_Handler and in
+Furthermore, the value returned by Current_Handler and in
Old_Handler must be null whenever the treatment is not a
@@ -27,18 +28,24 @@
invoked while the default treatment is still in force, the value in
Old_Handler can be dereferenced, with the dereference denoting a
parameterless protected procedure that can be called to obtain the
-default treatment. Is this the intent?
+default treatment. Is this the intent? [No.]
+C.3.2(16) and C.3.2(18) need to be changed to reflect the summary of
+in C.3.2(16): "...If no user-defined handler is attached to the interrupt,
+Current_Handler returns null. ..."
+in C.3.2(18): add "If the previous treatment is not a user-defined handler,
+null is returned."
-A key facts here are that a "treatment" of an interrupt (whether
+A key fact here is that a "treatment" of an interrupt (whether
default or user-defined) is not limited to execution of a handler,
and even if the treatment is to call a handler the handler may be
something other than a parameterless protected procedure.
@@ -179,10 +186,10 @@
| null, the default treatment is restored. ...
This binding interpretation extrapolates from the above to
-conclude that the value returned by Current_Task, and the value
+conclude that the value returned by Current_Handler, and the value
returned in Old_Handler by Exchange_Handler, must be the null
-access value whenever a the treatment that is in force the given
-signal is the default treatment. It further extrapolates to
+access value whenever the treatment that is in force for the
+given signal is the default treatment. It further extrapolates to
conclude that the null access value must be returned whenever the
treatment is not a user-installed handler. It follows that for
implementations that support only parameterless protected
@@ -197,7 +204,7 @@
This is a compromise. It does not provide the full capability
that the original question hoped for; i.e., there is no way to
"call" the default treatment. Likewise, if the implementation
-supports other forms of handler, and the application uses them,
+supports other forms of handlers, and the application uses them,
there remains the possibility that the value returned by
Current_Handler or in Old_Handler represents a handler that is not
a parameterless protected procedure, and so it would be erroneous
@@ -705,7 +712,7 @@
What is this AI saying?
-Apparently Norm wants to tighten the semantics for the default handler.
+Apparently Norm wants to tighten the semantics for the default handler.
This is counter to the principle of leaving the semantics vague to permit
implementation flexibility, especially on existing operating systems. Ted
complicates the situation by pointing out that an operating system can
Questions? Ask the ACAA Technical Agent