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
!class amendment 99-11-19
!status work item 99-11-19
@@ -15,8 +15,8 @@
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
@@ -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.
-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
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
+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
+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
+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.
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]
+-- 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
+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.
Questions? Ask the ACAA Technical Agent