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

Differences between 1.2 and version 1.3
Log of other versions for file ai05s/ai05-0033-1.txt

--- ai05s/ai05-0033-1.txt	2006/12/30 05:01:28	1.2
+++ ai05s/ai05-0033-1.txt	2007/12/13 04:39:35	1.3
@@ -1,6 +1,8 @@
-!standard 13.11.2(16)                                         06-12-15    AI05-0033-1/01
+!standard 13.11.2(16)                                         07-11-09    AI05-0033-1/02
+!standard C.3.1(7/2)
 !standard C.3.1(8/2)
 !class binding interpretation 06-12-15
+!status ARG Approved  9-0-0  06-11-09
 !status work item 06-12-15
 !status received 06-10-25
 !priority Low
@@ -10,7 +12,7 @@
 !summary
 
 (1) pragmas Interrupt_Handler and Attach_Handler are illegal in a protected type
-that is nested in a generic body. The library-level requirement is rechecked
+that is declared in a generic body. The library-level requirement is rechecked
 in instances, including private parts.
 
 (2) It is erroneous to dereference an access-to-protected-subprogram
@@ -46,7 +48,7 @@
 
 (2) AI95-303 allows objects with interrupt handlers to be declared
 anywhere (not just library-level). What does Interrupts.Current_Handler
-return in this case? It seems like is would be an access-to-subprogram
+return in this case? It seems like it would be an access-to-subprogram
 value that is not a legitimate value of the library-level
 Parameterless_Handler type, and represents a dangling
 reference possibility. Do we need some rules to handle this case?
@@ -64,16 +66,16 @@
 The corresponding protected_type_declaration or single_protected_declaration
 shall be a library-level declaration, and shall not be declared within a
 generic body. In addition to the places where Legality Rules normally apply
-(see 12.3), these rules applies also in the private part of an instance of a
+(see 12.3), these rules also apply in the private part of an instance of a
 generic unit.
 
 Existing AARM Discussion: In the case of a protected_type_declaration, an
 object_declaration of an object of that type need not be at library level. 
 
 New AARM Discussion: We cannot allow these pragmas in a generic body, because
-legality rules are not checked for instance bodies, and these would not be
+legality rules are not checked for instance bodies, and these should not be
 allowed if the instance is not at the library level. The protected types can
-be declared in the private part in that case. Note that while the 'Access to
+be declared in the private part if this is desired. Note that while the 'Access to
 use the handler would provide the check in the case of Interrupt_Handler, there
 is no other check for Attach_Handler. Since these pragmas are so similar, we
 want the rules to be the same.
@@ -83,13 +85,12 @@
 
 (2)
 
-Add to 13.11.2(16):
+Replace the first sentence of 13.11.2(16) by:
 
-Evaluation of a dereference denoting a protected subprogram is erroneous if
-the associated protected object no longer exists. [I don't think this
-is quite right! But it's close to the original wording for ordinary
-access types. Better ideas welcome. - RLB]
+Evaluating a name that denotes a nonexistent object or a protected subprogram whose
+associated object is nonexistent is erroneous.
 
+
 !discussion
 
 (1)
@@ -132,8 +133,8 @@
 protected object that no longer exists. (That is, it is a general issue). The
 accessibility check does not help here (like it does for regular access-to-subprograms),
 because the protected object could be allocated for a library-level access type and
-then deallocated with Unchecked_Deallocation. That shows that the interrupt case is not
-special; the problem can happen for any access-to-protected-subprogram.
+then deallocated with Unchecked_Deallocation. This example shows that the interrupt case
+is not special; the problem can happen for any access-to-protected-subprogram.
 
 13.11.2(16) says that evaluating a name that denotes a nonexistent object is erroneous.
 The question then becomes "does an access-to-protected-subprogram denote an object?" It's
@@ -141,9 +142,41 @@
 the access value clearly denotes a protected subprogram, which is not an object).
 Therefore, we add a rule covering this case.
 
+!corrigendum 13.11.1(16)
+
+@drepl
+Evaluating a name that denotes a nonexistent object is erroneous. The execution of a call
+to an instance of Unchecked_Deallocation is erroneous if the object was created other
+than by an allocator for an access type whose pool is Name'Storage_Pool. 
+@dby
+Evaluating a name that denotes a nonexistent object or a protected subprogram whose
+associated object is nonexistent is erroneous. The execution of a call to an instance
+of Unchecked_Deallocation is erroneous if the object was created other than
+by an allocator for an access type whose pool is Name'Storage_Pool. 
+
+!corrigendum C.3.1(7/2)
+
+@drepl
+The Attach_Handler pragma is only allowed immediately within the @fa<protected_definition>
+where the corresponding subprogram is declared. The corresponding
+@fa<protected_type_declaration> or @fa<single_protected_declaration> shall be a
+library-level declaration. 
+@dby
+The Attach_Handler and Interrupt_Handler pragmas are only allowed immediately
+within the @fa<protected_definition> where the corresponding subprogram is declared.
+The corresponding @fa<protected_type_declaration> or @fa<single_protected_declaration>
+shall be a library-level declaration, and shall not be declared within a
+generic body. In addition to the places where Legality Rules normally apply
+(see 12.3), these rules also apply in the private part of an instance of a
+generic unit.
 
---!corrigendum C.3.1(7/2)
+!corrigendum C.3.1(8/2)
 
+@ddel
+The Interrupt_Handler pragma is only allowed immediately within the @fa<protected_definition>
+where the corresponding subprogram is declared. The corresponding
+@fa<protected_type_declaration> or @fa<single_protected_declaration> shall be
+a library-level declaration. 
 
 !ACATS test
 

Questions? Ask the ACAA Technical Agent