CVS difference for ais/ai-00303.txt
--- ais/ai-00303.txt 2002/12/04 23:43:39 1.2
+++ ais/ai-00303.txt 2004/04/27 04:48:31 1.3
@@ -1,4 +1,4 @@
-!standard C.3.1 (08) 02-07-10 AI95-00303/01
+!standard C.3.1 (08) 04-04-26 AI95-00303/02
!standard C.3.1 (13)
!class binding interpretation 02-07-10
!status work item 02-07-10
@@ -10,11 +10,9 @@
-C.3.1(8) applies in the private part of an instance.
+There is no restriction on the location of objects of protected
+types containing Interrupt_Handler pragmas.
-A run-time check is applied in instance bodies that objects of protected
-types containing Interrupt_Handler pragmas are library-level.
The legality rule C.3.1(8) says:
@@ -72,7 +70,7 @@
check depends both on the actual parameter and the location of the
-When and how is this check done?
+When and how is this check done? (We don't need the check.)
@@ -80,7 +78,7 @@
+Delete the last sentence of C.3.1(8).
@@ -92,16 +90,43 @@
Another possible solution would be to prevent such protected types from
matching generic limited private types. This seems very inconsistent with
the rest of the language.
+A third solution would be a run-time check in instance bodies. Such a check
+would be very similar to the accessibility check (see 3.10.2(28-29)). In most
+implementations, this check could be made at compile-time, but implementations
+using some form of generic sharing may have to make the check at runtime. But
+such a check would potentially have runtime overhead, and certainly would
+add complexity to compilers.
+A better question is whether we need the rule at all. What is it trying to
+* It prevents the need to support non-library level interrupt handlers. But
+ pragma Attach_Handler already supports those. Besides, any attempt to
+ attach a non-library level handler is going to fail the accessibility check
+ when taking 'Access.
+* It eliminates the need to define what happens when interrupt handlers are
+ finalized. Yes, but we've already defined that behavior.
+* It prevents trouble if an ordinary call is made to an interrupt handler
+ routine. OK, but implementations are already given the permission to restrict
+ ordinary calls on such routines (that's the purpose that the AARM gives
+ for C.3.1(17)).
+Thus, it appears that there is no language need to enforce this rule. So, we
+drop the rule.
+This has no impact on implementations at all, as they can continue to enforce
+the old rule as an implementation-defined restriction (as defined in C.3.1(17)).
+Such restrictions can violate the contract model if the implementer wishes,
+while the language must not do that. If there is no problem with a nested
+object with an Interrupt_Handler pragma, the implementation can allow that,
+too. (Of course, such an object cannot actually handle interrupts because it's
+handlers would fail the accessibility check.)
-So we have adopted a run-time check in instance bodies. This check is very
-similar to the accessibility check (see 3.10.2(28-29)). In most
-implementations, this check can be made at compile-time, but implementations
-using some form of generic sharing may have to make the check at runtime.
-This rule unfortunately adds overhead to generic sharing implementations for
-an extremely unlikely case. Luckily, this overhead can be avoided in a partial
-sharing implementation (where instantiations with protected type actuals are
-not shared), so this affects only a handful of implementations.
+Removing this rule has no effect on the Ravenscar profile, as it already
+restricts all nested protected objects.
@@ -113,28 +138,11 @@
The Interrupt_Handler pragma is only allowed immediately within a
@fa<protected_definition>. The corresponding @fa<protected_type_declaration>
-shall be a library level declaration. In addition, any @fa<object_declaration>
-of such a type shall be a library level declaration. In addition to the
-places where Legality Rules normally apply (see 12.3), this rule applies also
-in the private part of an instance of a generic unit.
-When a handler is attached to an interrupt, the interrupt is blocked (subject
-to the Implementation Permission in C.3) during the execution of every
-protected action on the protected object containing the handler.
-For any object of a type containing a Interrupt_Handler pragma, a check is
-made that the object is declared at the library level. If this check fails,
-Program_Error is raised.
+shall be a library level declaration.
-A C-Test should be created to check that this rule is checked in
-an instance body (the example above). Add a test case to BXC3002 to check
-that this rule is enforced in the private part of a generic instance.
+Eliminate any existing test cases for objects from BXC3002.
Questions? Ask the ACAA Technical Agent