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

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

--- ai05s/ai05-0033-1.txt	2006/12/16 03:13:19	1.1
+++ ai05s/ai05-0033-1.txt	2006/12/30 05:01:28	1.2
@@ -111,16 +111,20 @@
 as it is not unusual to switch between the two.
 
 In the example in the question, legality rules are not checked in generic
-bodies of instances. However, there is a runtime check when the 'Access of
-the handler is used. So there is no need for additional rules for this case.
+bodies of instances. However, there is a legality check when the 'Access of
+the handler is used (it is always illegal [remember that access-to-subprogram
+checks are always at compile-time, and generic bodies use an assume-the-worst
+rule, rather than a runtime check]). So there is no need for
+additional rules for this case.
 
-However, a similar example for pragma Attach_Handler would not have a check.
+However, a similar example for pragma Attach_Handler would not have any check.
 So we do indeed need assume-the-worst rules banning the use of these pragmas
 in a generic bodies, and a recheck in private parts of generic specifications.
 
-There is a slight incompatibility with this change, but we believe that handlers
-in generic bodies will be rare, and such handlers can usually be moved to the
-private part of the generic where they are still legal.
+There is a slight incompatibility with this change, but any such handler
+would have to be unused (as taking 'Access in the body is illegal, as the type of
+the access is declared outside of the generic unit). That's a highly unlikely
+situation; the pragma should be removed in that case.
 
 (2)
 
@@ -129,13 +133,13 @@
 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.
+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 does an access-to-protected-subprogram denote an object? It's
+The question then becomes "does an access-to-protected-subprogram denote an object?" It's
 possible to argue that either way (an object is associated with the access value, but
-it clearly denotes a protected subprogram, which is not an object). Therefore, we add
-a rule covering this case.
+the access value clearly denotes a protected subprogram, which is not an object).
+Therefore, we add a rule covering this case.
 
 
 --!corrigendum C.3.1(7/2)

Questions? Ask the ACAA Technical Agent