CVS difference for ai05s/ai05-0157-1.txt
--- ai05s/ai05-0157-1.txt 2009/06/02 06:22:37 1.2
+++ ai05s/ai05-0157-1.txt 2009/07/11 03:06:22 1.3
@@ -1,15 +1,20 @@
-!standard 13.11.2(3) 09-06-02 AI05-0157-1/00
+!standard 13.11.2(3) 09-06-27 AI05-0157-1/01
!class binding interpretation 09-06-02
!status work item 09-06-02
!status received 09-02-15
-!subject Unchecked_Deallocation should be illegal for zero-sized pools
+!subject Calling Unchecked_Deallocation is illegal for zero-sized pools
-** TBD **
+Calling an instance of Unchecked_Deallocation is illegal if pool is
+known to have Storage_Size equal to zero.
+We recommend that an instance of Unchecked_Deallocation raise Program_Error
+if the pool has Storage_Size equal to zero (if it is not illegal).
@@ -22,43 +27,97 @@
Unchecked_Deallocation can be instantiated for such types, and every call
to such an Unchecked_Deallocation is guaranteed to be erroneous.
-Should such instances be illegal?
+Should such instances be illegal? (No, but calls are.)
+Add after 13.11.2(3):
-** TBD **
+A call on an instance of Unchecked_Deallocation is illegal if the actual
+access type of the instance is a type for which the Storage_Size has been
+specified by a static expression with value zero or is defined by the language
+to be zero. 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.
+This rule does not apply in the body of a generic unit or within a body declared
+within the declarative region of a generic unit, if the actual access type of
+the instance is a descendant of a formal access type declared within the formal
+part of the generic unit.
+[Editor's note: This is nearly a copy of 4.8(5.3/2).]
+Add after 13.11.2(17): (Implementation Advice)
+A call on an instance of Unchecked_Deallocation with a non-null access value should
+raise Program_Error if the actual access type of the instance is a type for which
+the Storage_Size has been specified to be zero or is defined by the language to be
+AARM Note: If the call is not illegal (as in a generic body), we recommend that
+it raise Program_Error. Since the execution of this call erroneous (any allocator
+from the pool will have raised Storage_Error, so the non-null access value must
+have been allocated from a different pool or be a stack-allocated object), we can't
+require any behavior - anything at all would be a legitimate implementation.
+[Editor's note: I don't think we want to raise Program_Error if the access value is null;
+that case is not erroneous and is defined to do nothing. It seems harmless.
+Humm, reading the wording of 13.11.2(16), one could argue that calling an instance of
+Unchecked_Deallocation with a null access value is *always* erroneous. It's not clear
+what "the object" is in that case, but surely it wasn't created by an allocator with
+Name'Storage_Pool. (Of course, even Adam would be embarassed to actually claim this
+seriously - no one could doubt the intent.) Do we need to clarify 13.11.2(16) in some
+way (perhaps an AARM To Be Honest note would be sufficient)?]
-We seem to have a number of choices here:
+We had a number of choices here:
(1) Make the instance of Unchecked_Deallocation illegal. But this is
weird, because this is a legality check unrelated to the (normal) generic
contract. It would be a magic extra check.
-(2) Raise Program_Error if such a generic instance is detected. This
-is less weird, but it turns what otherwise would be a legality rule into
-a runtime check. If it is a runtime check on cases that aren't currently
-detected by the legality rule, it could have a negative impact on generics
-that instantiate but do not call (in some cases) Unchecked_Deallocation.
-(Imagine a generic that determines whether or not to call Free based on
-an additional generic parameter; it would always have to instantiate it.)
+A second objection to this choice is that it would make instances of
+generics illegal if there is merely an instance of Unchecked_Deallocation
+in the specification. That is quite reasonable, and the instance would not
+necessarily be called. (Imagine a generic that determines whether or not
+to call Free based on an additional generic parameter; it would always have
+to instantiate it.) This would reduce the usability of generics.
+(2) Make calls on the instance of Unchecked_Deallocation illegal. This is
+also a magic check, but at least it doesn't run into issues with generic
-(3) Raise Program_Error on the *call* of such a generic instance.
+(3) Raise Program_Error if such a generic instance is detected. This
+is less weird, but it turns what otherwise would be a legality rule into
+a runtime check. This also could render some generics unusable (as in
+case (1)); this could even be a broader problem as the runtime check
+could cover cases that would not have been statically illegal.
+(4) Raise Program_Error on the *call* of such a generic instance. This
+also turns a legality rule into a runtime check, but at least it doesn't
+have the problems with generic units.
-(4) Leave calling the instantiation erroneous, but add a permission for
+(5) Leave calling the instantiation erroneous, but add a permission for
an implementation to reject any program that it can detect would have
erroneous execution. (One wonders if a similar permission should be
allowed for Bounded Errors.) OTOH, this too could cause trouble for
any code conditionally compiled. Probably it would be better to follow
the rule in 1.1.5(6) (which suggests a warning when the compiler can
+Since we want this to remain a legality rule, and we do not want to make
+generic units less useful, we have chosen option (2), along with a recommendation
+for option (4) if the call is legal but the size is known to be zero.
Questions? Ask the ACAA Technical Agent