CVS difference for ais/ai-00224.txt

--- ais/ai-00224.txt	2002/07/23 01:05:23	1.24
+++ ais/ai-00224.txt	2003/01/15 00:06:36	1.25
@@ -1,4 +1,4 @@
-!standard 11.5(1-8)                                  02-07-12  AI95-00224/06
+!standard 11.5(1-8)                                  03-01-14  AI95-00224/07
 !standard 11.5(27)
 !class amendment 99-11-19
 !status work item 99-11-19
@@ -15,8 +15,8 @@
 !problem
 
 Ada code sometimes depends on the canonical checking semantics of the language.
-Consider, for instance, an integer saturation arithmetic package. The multiply
-operation might look like:
+Consider, for instance, a non-negative integer saturation arithmetic package.
+The multiply operation might look like:
 
      function "*" (Left, Right : Saturation_Type) return Saturation_Type is
      begin
@@ -36,14 +36,14 @@
    pragma Unsuppress (identifier);
 
 The identifier argument of Unsuppress is the same as Suppress. Unsuppress can
-be used in the same places as Suppress, with the similar scoping rules.
+be used in the same places as Suppress, with similar scoping rules.
 
 Pragma Unsuppress revokes the permission to suppress a check, that is, it means
 that the given check must be performed.
 
 !wording
 
-Define "Checking pragmas" and add pragma Suppress to 11.5(1)
+Define "Checking pragmas" and add pragma Unsuppress to 11.5(1)
 ("Checking pragmas" is in italics):
 
 *Checking pragmas* give an implementation instructions on handling
@@ -69,7 +69,7 @@
 
 Delete 11.5(7) (it only refers to the On parameter).
 
-Change 11.5(8) to define the meaning of pragma UnSuppress and to remove the
+Change 11.5(8) to define the meaning of pragma Unsuppress and to remove the
 On parameter:
 
 A checking pragma applies to the named check in a specific region (see below),
@@ -79,22 +79,34 @@
 The region for a checking pragma given as a configuration pragma is the
 declarative region for the entire compilation unit to which it applies.
 
-[If a checking pragma applies to a generic instantiation or a call to a
-subprogram that has a pragma Inline applied to it, then the checking pragma
-also applies to the instance or subprogram body.]
-
-AARM Proof: An instance is copy of the generic at the place of the instantiation
-(see 12.3(12)); and inlined subprogram bodies are expanded at the place of the
-call (see 6.3.2). This rule just makes it clear that we meant that. Note that
-implementations are not required to suppress checks in these contexts, as this
-is a permission, not a requirement.
+[If a checking pragma applies to a generic instantiation, then the checking
+pragma also applies to the instance. If a checking pragma applies to a call to
+a subprogram that has a pragma Inline applied to it, then the checking pragma
+also applies to the inlined subprogram body.]
+
+AARM Proof: An instance is copy of the generic at the place of the
+instantiation (see 12.3(12)); and inlined subprogram bodies are expanded at the
+place of the call (see 6.3.2). This rule just makes it clear that we meant
+that.
+
+AARM Discussion: The rule means that any checks suppressed at the point of the
+instantiation or called are suppressed in the instance body or inlined
+subprogram body. Permissions that are revoked at that point are not included,
+of course. This is in addition to any checks that may be suppressed in the
+generic body or subprogram body. Note that implementations are not required to
+suppress checks in these contexts, as check suppression is always a permission,
+not a requirement.
 
 A pragma Suppress gives permission to an implementation to omit the named check
-for any entities to which it applies. A pragma Unsuppress revokes the permission
-given by pragma Suppress to omit the named check for any entities to which it
-applies. If there is no such permission at the point of a pragma Unsuppress,
-then the pragma has no effect. If permission has been given to suppress a given
-check, the check is said to be suppressed.
+for any entities to which it applies. If permission has been given to suppress
+a given check, the check is said to be suppressed.
+
+A pragma Unsuppress revokes the permission to omit the named check
+given by any pragma Suppress that applies at the the point of the
+pragma Unsuppress. The permission is revoked for the region to which
+the pragma Unsuppress applies. If there is no such permission at the point of
+a pragma Unsuppress, then the pragma has no effect. [A later Suppress pragma
+can renew the permission.]
 
 AARM Note: Unsuppress does not have an effect on the check suppression implicit
 in pragma Unchecked_Union. However, implementations should insure that it
@@ -117,10 +129,10 @@
 Add an additional note after 11.5(29):
 
 It is possible to give both a pragma Suppress and Unsuppress for the same check
-in the same declarative region. In that case, the last pragma given determines
-whether or not the check is suppressed. Similarly, it is possible to resuppress
-a check which has been unsuppressed by giving a pragma Suppress in an inner
-declarative region.
+immediately within the same declarative_part. In that case, the last pragma
+given determines whether or not the check is suppressed. Similarly, it is
+possible to resuppress a check which has been unsuppressed by giving a pragma
+Suppress in an inner declarative region.
 
 Add an entire new section in Annex J (obsolescent features) to describe the
 specific checking pragmas:
@@ -155,6 +167,14 @@
 Which checks are associated with a specific entity is not defined by this
 standard.
 
+AARM Discussion: Exactly which entit(ies) control whether a check is performed
+is not specified by the language. For example, in
+       pragma Suppress (Range_Check, On => A);
+       A := B;
+whether or not the range check is performed is not specified. The compiler may
+require that checks are suppressed on B or on the type of A in order to
+suppress the range check.
+
                          Implementation Permissions
 
 An implementation is allowed to place restrictions on specific Suppress pragmas.
@@ -4453,6 +4473,45 @@
 inherit into Blah.
 
 The author finds this argument compelling. He hopes that the full ARG agrees.
+
+************************************************************
+
+[Editor's notes, January 14, 2003]
+
+Wording changes:
+-- Adjusted problem example as suggested at Bedford meeting;
+-- Split wording of 11.5(8.1) into two sentences;
+-- Clarified the wording of the second sentence of 11.5(8);
+-- Added an AARM note to the static semantics section of J.XX.
+
+I did not follow Tucker's suggestion from the meeting for 11.5(8.1). From the
+minutes:
+
+Tucker suggests changing the bracketed text to say if a Suppress pragma applies
+to the instance body or inlined copy, the unrevoked permissions also apply to
+the instance body or inlined copy. Or perhaps make it "unspecified" (we don't
+want to force documentation of this, so it can't be implementation-defined).
+
+This change would be wrong; we need to say that the Unsuppress pragma applies
+there as well. I did add an AARM note to this effect, to clarify the intent
+for future generations of implementers.
+
+There are two unrelated issues here: the region to which an Unsuppress pragma
+revokes permissions, and exactly what permissions are revoked. The original
+wording rather confused those issues, as it isn't particularly important for
+permissions to be precise. (If the permission is not used, that is the same
+as the permission being ignored, which is always OK). For Unsuppress, the rules
+are different: the checks whose permissions are revoked are only those in effect
+at the point of the pragma. The region over which the permissions are revoked
+are the same as for Suppress.
+
+Thus, I've retained the checking pragma wording for the "region" portion of
+definition. We definitely want the regions of application to be identical for
+Suppress and Unsuppress, so we want to share that wording. OTOH, we use
+special wording for Unsuppress to specify which permissions are revoked.
+
+Since we are using the checking pragma wording for regions, it is important
+that those regions include instances and inlined bodies.
 
 ************************************************************