CVS difference for ais/ai-00224.txt
--- ais/ai-00224.txt 2000/06/20 04:22:44 1.20
+++ ais/ai-00224.txt 2000/11/04 01:10:28 1.21
@@ -1,4 +1,4 @@
-!standard 11.5(1-8) 00-03-23 AI95-00224/03
+!standard 11.5(1-8) 00-11-03 AI95-00224/04
!standard 11.5(27)
!class amendment 99-11-19
!status work item 99-11-19
@@ -33,10 +33,10 @@
A new pragma Unsuppress is defined.
- pragma Unsuppress (identifier [, [On =>] name]);
+ 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 same scoping rules.
+be used in the same places as Suppress, with the similar scoping rules.
Pragma Unsuppress revokes the permission to suppress a check, that is, it means
that the given check must be performed.
@@ -51,38 +51,43 @@
to omit certain language-defined checks, while a pragma Unsuppress revokes the
permission to omit checks.
-Add pragma Unsuppress to 11.5(3-4):
+Add pragma Unsuppress to 11.5(3-4), and remove the On parameter from Suppress:
The forms of checking pragmas are as follows:
- pragma Suppress(identifier [, [On =>] name]);
- pragma Unsuppress(identifier [, [On =>] name]);
+ pragma Suppress(identifier);
+ pragma Unsuppress(identifier);
Change 11.5(5) to apply to checking pragmas:
A checking pragma is allowed only immediately within a declarative_part,
immediately within a package_specification, or as a configuration pragma.
-Change 11.5(7) to apply to checking pragmas:
+Change 11.5(6) to remove the reference to the On parameter:
-For a checking pragma that is immediately within a package_specification
-and includes a name, the name shall denote an entity (or several overloaded
-subprograms) declared immediately within the package_specification.
+The identifier shall be the name of a check.
-Change 11.5(8) to define the meaning of pragma UnSuppress:
+Delete 11.5(7) (it only refers to the On parameter).
-A checking pragma applies to the named check from the place of the pragma to
-the end of the innermost enclosing declarative region, or, if the pragma is
-given in a package_specification and includes a name, to the end of the scope
-of the named entity. If the pragma includes a name, the pragma applies only to
-the named entity, or, for a subtype, on objects and values of its type.
-Otherwise, the pragma applies to all entities. 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 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.
+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),
+and applies to all entities in that region. A pragma Suppress applies from the
+place of the pragma to the end of the innermost enclosing declarative region. A
+pragma Unsuppress given in a declarative_part applies from the place of the
+pragma to the end of the innermost enclosing declarative region, but not in any
+subunits of that declarative_part. A pragma Unsuppress given in a
+package_specification from the place of the pragma to the end of the
+specification. The region to which a pragma Unsuppress given as a configuration
+pragma applies is implementation-defined.
+
+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
+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.
Change 11.5(27) to apply to checking pragmas:
@@ -93,18 +98,6 @@
Overflow_Check has been suppressed, an implementation may also suppress
an unspecified subset of the Range_Checks.
-Add after 11.5(27):
-
-If more than one checking pragma which apply to the same check are
-given as configuration pragmas in different compilations, it is
-implementation-defined whether the check is suppressed.
-
-If an implementation supports the On parameter to pragma Unsuppress, the exact
-entities for which an Unsuppress pragma with an On parmameter revokes a check
-are implementation-defined. [In particular, whether checks suppressed with a
-general pragma Suppress (one without an On parameter) are revoked is
-implementation-defined.]
-
Add an additional note after 11.5(29):
It is possible to give both a pragma Suppress and Unsuppress for the same check
@@ -113,6 +106,45 @@
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:
+
+J.XX Specific Suppression of Checks
+
+Checking pragmas can be used to suppress checks on specific entities.
+
+ Syntax
+
+The forms of specific checking pragmas are as follows:
+
+ pragma Suppress(identifier, [On =>] name);
+ pragma Unsuppress(identifier, [On =>] name);
+
+ Legality Rules
+
+The identifier shall be the name of a check (see 11.5). The name shall
+statically denote some entity.
+
+For a specific checking pragma that is immediately within a
+package_specification, the name shall denote an entity (or several overloaded
+subprograms) declared immediately within the package_specification.
+
+ Static Semantics
+
+A specific checking pragma applies to the named check from the place of the
+pragma to the end of the innermost enclosing declarative region, or, if the
+pragma is given in a package_specification, to the end of the scope
+of the named entity. The pragma applies only to the named entity, or, for a
+subtype, on objects and values of its type. A specific pragma Suppress
+suppresses the named check for any entities to which it applies (see 11.5).
+The meaning of a specific pragma Unsuppress is implementation-defined.
+
+ Implementation Permissions
+
+An implementation is allowed to place restrictions on specific checking pragmas.
+
+
+
!example
We can use pragma Unsuppress to insure that checking occurs in the saturation
@@ -176,41 +208,55 @@
an Unsuppress pragma, or if a Unsuppress configuration pragma was used. This
would essentially be the current problem all over again, so the model where
Unsuppress has precedence over Suppress was rejected.
+
+
+Pragma Suppress can be inherited into other compilation units. In particular,
+a pragma Suppress used in a package specification also applies to the package
+body, and a pragma Suppress also applies to any subunits in the declarative
+region. This inheritance is not commonly implemented by Ada 95 compilers. This
+is OK, as the permission to suppress checks can always be ignored. However, the
+situation for Unsuppress is different. If it fails to inherit properly, checks
+might be suppressed that should not be. This could badly break programs.
+
+It also is preferable that an Unsuppress pragma be visible in any scope to
+which it applies. This prevents surprises as to why a particular entity is not
+suppressed.
+
+Thus, both to follow the principle of least surprise, and to avoid forcing
+implementations to implement inheritance of checking pragmas, we define
+pragma Unsuppress to not inherit into subunits or package bodies.
+
+Note that we also extent this to the use of Unsuppress as a configuration
+pragma. We leave the definition of the scope of such a pragma to
+implementations; this avoids perturbing implementations compilation strategies
+for a mostly useless pragma.
+
-Both pragmas Suppress and Unsuppress can be used as configuration pragmas.
-While it may it may seems that Unsuppress would be useless as a configuration
-pragma, it can be useful in conjunction with a Suppress pragma. For instance,
-the following pragmas would suppress all checks except storage checks in the
-entire program:
-
- pragma Suppress (All_Checks);
- pragma Unsuppress (Storage_Check);
-
-The exact meaning of a checking pragma when there is more than one in a
-particular declarative region depends on the order that it is given in. For
-example, reversing the order of the pragmas in the above example would simply
-suppress all checks. This poses a problem for configuration pragmas, though,
-as the order of configuration pragmas depends on the compilation model of the
-implementation. Of course, pragmas given in a single compilation have a
-well-defined order, so this gives us a solution which both allows the portable
-use of the pragmas without adding implementation burden. That is, we say that
-the meaning of conflicting checking pragmas given as configuration pragmas is
-implementation-defined unless the pragmas are given in the same compilation.
+We do have to define Unsuppress as a configuration pragma. Otherwise,
+implementations would be barred from supporting it that way (implementations
+cannot extend language-defined pragmas). But we do not want to force existing
+implementations to make these illegal, nor do we want to force a particular
+meaning on implementations. Thus, this usage is implementation-defined.
+
Restrictions can be placed on pragma Unsuppress. This is necessary to avoid
-burdening implementations. For instance, some implementations cannot support
-fine-grained suppression of single objects, and we don't want to start
-requiring that. We do require that any check names supported for Suppress is
-also supported for Unsuppress, because it is important to be able to unsuppress
-checks suppressed over a larger area. Note that the reverse is not true;
-implementations can support more of Unsuppress than of Suppress if they desire.
-
-The entities which have their checks revoked by an Unsuppress pragma with an
-On parameter are implementation-defined. This is necessary both because it
-is impossible to tightly define the meaning of Suppress and for implementation
-reasons.
+burdening implementations implementing items for which no Suppress support is
+provided. We do require that any check names supported for
+Suppress is also supported for Unsuppress, because it is important to be able
+to unsuppress checks suppressed over a larger area. Note that the reverse is
+not true; implementations can support more of Unsuppress than of Suppress if
+they desire.
+
+
+Checking pragmas with an On parameter are moved in the obsolescent features
+section. That was done because these features are inherently non-portable, and
+we want to discourage their use.
+
+Compiler surveys determined that the implementation of On parameters on pragma
+Suppress vary widely, even for implementations with the same target. It does not
+seem valuable to try to bring any portability to this area.
-One issue is that exactly which entit(ies) control when a check is performed
+For instance, exactly which entit(ies) control when a check is performed
is (purposely) not defined. In
A := B;
whether the range check is performed may depend whether checks are suppressed
@@ -221,75 +267,13 @@
example? A, B, or the type of A? The answer probably varies from implementation
to implementation, and there is little value in defining it more tightly.
-There is also an implementation issue. Implementations typically use a set
-of flags for non-specific Suppress pragmas (those without On parameters),
-and flags on individual entities for Suppress pragmas with On parameters.
-However, if something like
- pragma Suppress (Index_Check);
- ...
- pragma Unsuppress (Index_Check, On => A);
-occurs, the implementation would need to support "Suppress all index checks
-except those on A". Doing so would require either getting rid of the set of
-non-specific flags (using only the entity flags, which would make non-specific
-Suppresses quite expensive, as the entire symbolable would need to be walked
-when the suppression state changed), or implementing some sort of exception
-list. This implementation burden is not worth it for a capability whose meaning
-is implementation-defined anyway.
-
-Notice that the inverse case does not suffer from either of these problems.
-If a non-specific Unsuppress revokes a check on a specific entity, there is
-no gray area as to whether the check is performed or not. For example, in
- pragma Suppress (Access_Check, On => Some_Subtype);
- ...
- Obj : Some_Subtype;
- pragma Unsuppress (Access_Check);
- ...Obj.all...
-it does not matter if the check is made on Obj or on Some_Subtype, because
-we know the check will be performed.
-
-Alternative rules would likely be a surprise to users. If a user writes
- pragma Unsuppress (All_Checks);
-in some scope, they would be very surprised to discover that any checks are
-still suppressed. Moreover, if there were any checks still suppressed, the
-value of pragma Unsuppress as a portable preventative pragma is weakened:
-whether or not the program works may depend on the compiler used.
-
-Finally, the implementation of the revokation of specific checks is not
-difficult. It only requires that some way exist to find all of the entities
-which have had a pragma Suppress with an On parameter applied to them. A
-list would be appropriate, as the number of such entities will usually be
-small. At the application of a pragma Unsuppress, the list would be checked,
-flags changed on any entities that need it, and the changes stacked in the
-same way that local Suppress pragmas are handled. Unlike a Unsuppress pragma
-with an On parameter, no changes to the flags or added exception lists are
-needed.
-
-
-One minor surprise with checking pragmas is that an inherited pragma can
-override an explicitly given one. Checking pragmas are inherited into the
-bodies of packages when they are given in a specification. For example:
- package My_Pack is
- pragma Unsuppress (Access_Check);
- end My_Pack;
-
- pragma Suppress (Access_Check);
- package body My_Pack is
- -- pragma Unsuppress (Access_Check) inherited here.
- -- Access_Checks are not suppressed in this body.
- end My_Pack;
-
-Since the configuration pragma is outside of the package body, it is revoked
-by the inner, inherited Unsuppress pragma. While this may be momentarily
-surprising, it follows from the standard scoping rules. This case is more
-common than appears at first glance, as configuration pragmas can occur from
-compiler options.
-
-In the case given in the example, the result is probably what we want -- we
-do not want checks to disappear because of a compiler switch if there is an
-explicit Unsuppress somewhere. Unsuppress configuration pragmas will be rare,
-as they usually don't have any Suppresses to revoke. Thus, we don't need to
-consider its impact here. Since there is no clear advantage to a special rule
-to cover inherited pragmas, we simply use the natural interpretation.
+Rather than making any effort here, the meaning of pragma Unsuppress with an
+On parameter is implementation-defined. This is done so that existing
+implementations supporting this form can continue to do so. But we expect most
+implementations to define that all such pragmas are ignored.
+
+A benefit to making On parameters obsolescent is that this also signals
+implementors to spend little or no effort in this area.
Implementations should not produce warnings for usages of pragma Unsuppress
@@ -298,97 +282,11 @@
a usage may very well be a "preventative" pragma, inserted to insure that
checks are made in a unit that requires checks.
-
-Alternative names (in particular "Require") were considered for this pragma.
-The name Unsuppress has two problems: First, it is a dubious English word; Ada
-pragmas are usually English words or phrases. Secondly, the preventative use of
-this pragma is very important, but "Unsuppress" appears to denote something
-that can only be used when checks actually are suppressed. This would likely
-lead to the under-use of the pragma as a preventative.
-
-Irregardless, we use "Unsuppress" as the name of the pragma. There were two
-main factors for this. First, Unsuppress implies a relationship with Suppress,
-which other names cannot do. Second, Unsuppress is in current use as an
-extension in several compilers, and standardizing existing practice is
-usually better than inventing new ideas.
-
-
-An alternative definition was suggested that would eliminate the need to make
-the meaning of Unsuppress with an On parameter implementation-defined.
-The idea of the alternative definition is to have pragma Unsuppress revoke
-a particular Suppress pragma, rather than revoking a check. Doing so
-avoids the implementation dependence of what exactly is checked, because
-the pragmas involved are well-defined.
-
-However, this approach has a substantial impact on usability, and there is also
-difficulty in defining exactly what is revoked, especially in the On parameter
-cases.
-
-The problems with defining what is revoked come from that fact that the check
-names are not disjoint. For instance, the check name All_Checks is defined to
-be the union of all defined checks. Does a checking pragma using All_Checks
-match a pragma using some other check? If it does, then particular pragmas
-need to be able to match sets and portions of other pragmas.
-For instance:
+Alternative names and definitions were considered for this pragma. These were
+ultimately rejected in order to standardize current practice, and to simplify
+the presentation. Some of these are discussed in the Appendix.
- pragma Suppress (Access_Check);
- pragma Suppress (Index_Check);
- ....
- pragma Unsuppress (All_Checks);
-
-In this case, does Unsuppress (All_Checks) revoke both pragmas?
-
-Similarly:
-
- pragma Suppress (All_Checks);
- ....
- pragma Unsuppress (Index_Check);
-
-In this case, does Unsuppress (Index_Check) revoke the "Index_Check" portion
-of the pragma Suppress?
-
-A similar problem occurs for the On parameter, as separate entities may not in
-fact have separate checks. For instance, 11.5(8) clearly states that checks
-are defined on types, not on subtypes. However, two different subtypes of the
-same type are clearly separate entities. Does an Unsuppress on one of the
-subtypes revoke a check suppressed on the other? These sort of questions
-immediately lead back into the morass that we are trying to avoid.
-
-This definition also suffers from a usability problem. A pragma Unsuppress
-does not revoke checks on a non-matching pragma Suppress. This greatly
-reduces the usefulness of the pragma as a preventative, as a pragma Suppress
-added elsewhere in the source of a program can leak into a supposedly
-Unsuppressed program region.
-
-Consider:
-
- package Something is
- ...
- pragma Suppress (Access_Check, On => Some_Subtype);
- end Something;
-
- with Something;
- procedure Needs_Checks is
- pragma Unsuppress (All_Checks);
- -- Make sure that all checks are made in this unit.
- Obj : Something.Some_Subtype;
- begin
- ... Obj.all ... -- Oops, no check made here.
- exception
- when Constraint_Error => ...
- end Needs_Checks;
-
-Since the pragma Suppress does not "match" the pragma Unsuppress, the
-Access_Check on Obj is still suppressed, and the exception handler will
-not be invoked. Worse, the insertion of a pragma Suppress in some unit
-can break code in a unit far away. This is the sort of problem that we try to
-prevent in Ada, and the cost to do so in this case is not high.
-
-While this problem can be mitigated somewhat by expanding the matching rules,
-doing so adds complications, and makes the resulting solution similar
-to the one proposed.
-
!appendix
*************************************************************
@@ -2861,8 +2759,6 @@
*************************************************************
-*************************************************************
-
From: Randy Brukardt
Sent: Friday, March 17, 2000 3:53 PM
@@ -3883,6 +3779,364 @@
I was directed to looking into the possibility of defining different rules
for Unsuppress than Suppress (especially for inheritance).
+
+*************************************************************
+
+From: Editor
+
+An off-line discussion with Robert Dewar, Tucker Taft, Bob Duff, and
+Joyce Tokar in April 2000 about the current state of On => parameters to
+suppress uncovered the following facts:
+
+In the following example:
+ subtype X is Integer range 1 .. 10;
+ pragma Suppress (Range_Check, On => X);
+is supposed to suppress the checks on the TYPE (Integer in this case), as per
+11.5(8). This is much too wide.
+
+Averstar's compiler does not allow a pragma like the above if the subtype is
+outside of the declarative part of the type. Thus, the above won't work.
+
+If we have:
+ A, B, C : X; -- X as above.
+ ...
+ A := B + C;
+which objects need to be suppressed in order to remove the range check on := varies
+from compiler to compiler. For some reason, Averstar needs the RHS object
+suppressed, while GNAT and DDCI need the LHS object. Moreover, whether or not
+the check is a range check or an overflow check depends on the compiler; and
+so that the suppression of the check still varies.
+
+The result of the discussion is that there is not and probably cannot be any
+commonality here. However, the RM language seems to imply that these uses are
+portable. Everyone agreed that the effort to fix the RM language is not
+worthwhile. The best solution was felt to be to move Suppress (..., On => ...)
+into Annex J (making it an obsolescent feature).
+
+*************************************************************
+
+From: Editor
+
+ Implementation Survey for AI-00224.
+
+ Subtest A - Suppress(All_Checks) supported.
+ Subtest B - Suppress(All_Checks) in package spec inherited in body.
+ Subtest C - Suppress(All_Checks) supported as a source specific config. pragma.
+ Subtest D - Suppress(All_Checks) config pragma on package spec inherited in body.
+ Subtest E - Unsuppress supported.
+ Subtest F - Suppress(All_Checks, On => Object) supported.
+ Subtest G - Suppress(All_Checks, On => Object) inherited from package spec.
+ Subtest H - Unsuppress in body overrides configuration Suppress in body.
+ Subtest J - Unsuppress in spec overrides configuration Suppress in body.
+ Subtest K - Suppress in spec overrides configuration Unsuppress in body.
+ Subtest M - Non-specific Unsuppress overrides Suppress(All_Checks, On => Obejct).
+
+ Subtest
+Compiler Source A B C D E F G H J K M
+Janus/Ada 3.1.2 Randy Y N Y N Y N - Y - - -
+GNAT 3.1.2a3 Randy Y N Y N Y N - Y - - -
+GNAT (version not given)
+ Robert Dewar Y N Y N Y Y Y Y - - Y
+GNAT 3.1.3a* Randy Y N Y N Y Y Y Y - - N
+Rational 3.0.2b Randy Y N Y N N Y Y - - - -
+AdaMagic 3.301 Tucker Taft Y Y Y Y Y N - Y N Y -
+ICC (version not given)
+ Dan Eilers Y N Y N N N - - - - -
+DDCI (version not given)
+ Joyce Tokar Y Y Y X Y N - Y Y Y -
+OcSystems Faez Kaiser X
+DDCI (version not given)*
+ Joyce Tokar Y Y Y N Y Y Y Y Y Y Y
+
+
+ Y - Supported. N - Not supported. X - Compiler bug or crash. - - Not applicable.
+
+ * - The test run on GNAT 3.13a used a modified version of Chk_224h; the original version had the same results as 3.12a3.
+ The second test run on DDCI used the same modified version as used for GNAT 3.13a.
+
+*************************************************************
+
+From: Editor
+
+(Editor's note: the following used to be in the !Discussion of the AI. In
+simplifying the AI, I removed this; but it still might be useful, so I've
+attached it here.)
+
+
+Alternative names (in particular "Require") were considered for this pragma.
+The name Unsuppress has two problems: First, it is a dubious English word; Ada
+pragmas are usually English words or phrases. Secondly, the preventative use of
+this pragma is very important, but "Unsuppress" appears to denote something
+that can only be used when checks actually are suppressed. This would likely
+lead to the under-use of the pragma as a preventative.
+
+Irregardless, we use "Unsuppress" as the name of the pragma. There were two
+main factors for this. First, Unsuppress implies a relationship with Suppress,
+which other names cannot do. Second, Unsuppress is in current use as an
+extension in several compilers, and standardizing existing practice is
+usually better than inventing new ideas.
+
+
+An alternative definition was suggested that would eliminate the need to make
+the meaning of Unsuppress with an On parameter implementation-defined.
+The idea of the alternative definition is to have pragma Unsuppress revoke
+a particular Suppress pragma, rather than revoking a check. Doing so
+avoids the implementation dependence of what exactly is checked, because
+the pragmas involved are well-defined.
+
+However, this approach has a substantial impact on usability, and there is also
+difficulty in defining exactly what is revoked, especially in the On parameter
+cases.
+
+The problems with defining what is revoked come from that fact that the check
+names are not disjoint. For instance, the check name All_Checks is defined to
+be the union of all defined checks. Does a checking pragma using All_Checks
+match a pragma using some other check? If it does, then particular pragmas
+need to be able to match sets and portions of other pragmas.
+
+For instance:
+
+ pragma Suppress (Access_Check);
+ pragma Suppress (Index_Check);
+ ....
+ pragma Unsuppress (All_Checks);
+
+In this case, does Unsuppress (All_Checks) revoke both pragmas?
+
+Similarly:
+
+ pragma Suppress (All_Checks);
+ ....
+ pragma Unsuppress (Index_Check);
+
+In this case, does Unsuppress (Index_Check) revoke the "Index_Check" portion
+of the pragma Suppress?
+
+A similar problem occurs for the On parameter, as separate entities may not in
+fact have separate checks. For instance, 11.5(8) clearly states that checks
+are defined on types, not on subtypes. However, two different subtypes of the
+same type are clearly separate entities. Does an Unsuppress on one of the
+subtypes revoke a check suppressed on the other? These sort of questions
+immediately lead back into the morass that we are trying to avoid.
+
+This definition also suffers from a usability problem. A pragma Unsuppress
+does not revoke checks on a non-matching pragma Suppress. This greatly
+reduces the usefulness of the pragma as a preventative, as a pragma Suppress
+added elsewhere in the source of a program can leak into a supposedly
+Unsuppressed program region.
+
+Consider:
+
+ package Something is
+ ...
+ pragma Suppress (Access_Check, On => Some_Subtype);
+ end Something;
+
+ with Something;
+ procedure Needs_Checks is
+ pragma Unsuppress (All_Checks);
+ -- Make sure that all checks are made in this unit.
+ Obj : Something.Some_Subtype;
+ begin
+ ... Obj.all ... -- Oops, no check made here.
+ exception
+ when Constraint_Error => ...
+ end Needs_Checks;
+
+Since the pragma Suppress does not "match" the pragma Unsuppress, the
+Access_Check on Obj is still suppressed, and the exception handler will
+not be invoked. Worse, the insertion of a pragma Suppress in some unit
+can break code in a unit far away. This is the sort of problem that we try to
+prevent in Ada, and the cost to do so in this case is not high.
+
+While this problem can be mitigated somewhat by expanding the matching rules,
+doing so adds complications, and makes the resulting solution similar
+to the one proposed.
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, November 02, 2000 10:20 PM
+
+Following is the proposed wording of 11.5 to support Unsuppress. This is the
+complete clause (except as noted); it is a lot clearer than the wording in
+the AI, which notes the paragraphs changed and the reasons. I'm still
+working on the !discussion section of the AI (it needs a complete rewrite
+and simplification), so the whole new AI isn't available yet (probably
+tomorrow).
+
+The version is different from the last one in the following ways:
+
+1) Specific Suppress (with On parameters) is declared obsolescent, and moved
+to Annex J;
+
+2) Pragma Unsuppress does not inherit into other compilation units other
+than the one it is specified in. (Pragma Suppress in a package specification
+inherits into the package body, and also into any subunits. However, this
+inheritance is not widely implemented in Ada 95 compilers, and we don't want
+to force compilers to support it for
+Unsuppress.) Thus, we define the "region" to which Suppress and Unsuppress
+applies separately.
+
+3) The region to which a pragma Unsuppress used as a configuration pragma
+applies is implementation-defined.
+(I know that the ARG would rather that we did not define Unsuppress as a
+configuration pragma at all, but this is necessary to support existing
+implementations. See question 2 below.)
+
+Questions:
+
+1) I just moved the existing wording for specific Suppress to Annex J. Do we
+need a statement that the checks suppressed are implementation-dependent?
+(This came up multiple times in the E-Mail, but I don't know whether we want
+to add that to the wording or just leave it implicit.)
+
+2) It would be simpler to not define Unsuppress with an On parameter, and
+Unsuppress as a configuration parameter. (The first being problematic, and
+the second being almost useless.) The problem is, that this would be
+incompatible with existing implementations. That is, when (in the distant
+future) Unsuppress becomes an official part of the language, it would no
+longer be legal to support it as a configuration pragma or for it to have
+the additional parameter.
+(Implementations are not allowed to extend language-defined pragmas.) That
+would be incompatible with most of the existing implementations, especially
+GNAT. To date, the consensus has been that we don't want to force GNAT or
+other implementations to change. Has this changed? (I think it would be bad
+policy to adopt an amendment that we would not add to the language without a
+significant change, so I think we need to deal with this issue now.)
+
+3) Other comments are welcome. But I think actual wordsmithing on this text
+is premature. FYI, paragraphs 2, 9-26, 28-29, 30-31 are unchanged. I've
+included them below for ease of reading.
+
+ Randy.
+
+---------
+
+
+11.5 Suppressing Checks
+
+
+1 Checking pragmas give an implementation instructions on handling
+language-defined checks. A pragma Suppress gives permission to an
+implementation to omit certain language-defined checks, while a pragma
+Unsuppress revokes the permission to omit checks.
+
+2 A language-defined check (or simply, a ``check'') is one of the
+situations defined by this International Standard that requires a check to
+be made at run time to determine whether some condition is true. A check
+fails when the condition being checked is false, causing an exception to be
+raised.
+
+
+ Syntax
+
+3 The forms of checking pragmas are as follows:
+
+4 pragma Suppress(identifier);
+ pragma Unsuppress(identifier);
+
+5 A checking pragma is allowed only immediately within a declarative_part,
+immediately within a package_specification, or as a configuration pragma.
+
+
+ Legality Rules
+
+6 The identifier shall be the name of a check.
+
+
+ Static Semantics
+
+8 A checking pragma applies to the named check in a specific region (see
+below), and applies to all entities in that region. A pragma Suppress
+applies from the place of the pragma to the end of the innermost enclosing
+declarative region. A pragma Unsuppress given in a declarative_part applies
+from the place of the pragma to the end of the innermost enclosing
+declarative region, but not in any subunits of that declarative_part. A
+pragma Unsuppress given in a package_specification from the place of the
+pragma to the end of the specification. The region to which a pragma
+Unsuppress given as a configuration pragma applies is
+implementation-defined.
+
+8.1 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 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.
+
+9 The following are the language-defined checks:
+
+(* Omitted, these are not modified by this proposal *)
+
+ Erroneous Execution
+
+26 If a given check has been suppressed, and the corresponding error
+situation occurs, the execution of the program is erroneous.
+
+
+ Implementation Permissions
+
+27 An implementation is allowed to place restrictions on checking pragmas,
+subject only to the requirement that pragma Unsuppress shall allow any check
+names supported by pragma Suppress. An implementation is allowed to add
+additional check names, with implementation-defined semantics. When
+Overflow_Check has been suppressed, an implementation may also suppress an
+unspecified subset of the Range_Checks.
+
+
+ Implementation Advice
+
+28 The implementation should minimize the code executed for checks that
+have been suppressed.
+
+ NOTES
+
+29 There is no guarantee that a suppressed check is actually removed; hence
+a pragma Suppress should be used only for efficiency reasons.
+
+29.1 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.
+
+
+J.X Specific Suppression of Checks
+
+0.1 Checking pragmas can be used to suppress checks on specific entities.
+
+ Syntax
+
+0.2 The forms of specific checking pragmas are as follows:
+
+0.3 pragma Suppress(identifier, [On =>] name);
+ pragma Unsuppress(identifier, [On =>] name);
+
+ Legality Rules
+
+0.4 The identifier shall be the name of a check (see 11.5). The name shall
+statically denote some entity.
+
+0.5 For a specific checking pragma that is immediately within a
+package_specification, the name shall denote an entity (or several
+overloaded subprograms) declared immediately within the
+package_specification.
+
+ Static Semantics
+
+0.6 A specific checking pragma applies to the named check from the place of
+the pragma to the end of the innermost enclosing declarative region, or, if
+the pragma is given in a package_specification, to the end of the scope of
+the named entity. The pragma applies only to the named entity, or, for a
+subtype, on objects and values of its type. A specific pragma Suppress
+suppresses the named check for any entities to which it applies (see 11.5).
+The meaning of a specific pragma Unsuppress is implementation-defined.
+
+ Implementation Permissions
+
+0.7 An implementation is allowed to place restrictions on specific checking
+pragmas.
*************************************************************
Questions? Ask the ACAA Technical Agent