CVS difference for ais/ai-00224.txt

--- ais/ai-00224.txt	1999/12/10 01:13:30	1.8
+++ ais/ai-00224.txt	1999/12/13 20:23:49	1.9
@@ -1,11 +1,11 @@
-!standard 11.5(1-8)                                  99-11-19  AI95-00224/01
+!standard 11.5(1-8)                                  99-12-13  AI95-00224/02
 !standard 11.5(27)
 !class amendment 99-11-19
 !status work item 99-11-19
 !status received 99-11-19
 !priority Medium
 !difficulty Medium
-!subject pragma Require
+!subject pragma Unsuppress
 
 !summary
 
@@ -31,31 +31,32 @@
 
 !proposal
 
-A new pragma Require is defined.
+A new pragma Unsuppress is defined.
 
-   pragma Require (identifier [, [On =>] name]);
+   pragma Unsuppress (identifier [, [On =>] name]);
 
-The arguments of Require are the same as Suppress. Require can be used in the
-same places as Suppress, with the same scoping rules.
+The arguments of Unsuppress are the same as Suppress. Unsuppress can be used in
+the same places as Suppress, with the same scoping rules.
 
-Pragma Require means that the given check must be performed.
+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 Require to 11.5(1)
+Define "Checking pragmas" and add pragma Suppress to 11.5(1)
 ("Checking pragmas" is in italics):
 
 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 Require requires an
-implementation to make certain language-defined checks.
+to omit certain language-defined checks, while a pragma Unsuppress revokes the
+permission to make omit checks.
 
-Add pragma Require to 11.5(3-4):
+Add pragma Unsuppress to 11.5(3-4):
 
 The forms of checking pragmas are as follows:
 
-     pragma Require(identifier [, [On =>] name]);
      pragma Suppress(identifier [, [On =>] name]);
+     pragma Unsuppress(identifier [, [On =>] name]);
 
 Change 11.5(5) to apply to checking pragmas:
 
@@ -68,7 +69,7 @@
 and includes a name, the name shall denote an entity (or several overloaded
 subprograms) declared immediately within the package_specification.
 
-Change 11.5(8) to define the meaning of pragma Require:
+Change 11.5(8) to define the meaning of pragma UnSuppress:
 
 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
@@ -77,26 +78,42 @@
 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, but not for any entity to which a pragma Require applies. If
+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:
 
 An implementation is allowed to place restrictions on checking pragmas,
-subject only to the requirement that pragma Require shall allow any arguments
-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.
+subject only to the requirement that pragma Unsuppress shall allow any
+arguments 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.
+
+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.
+
+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.
 
 !example
 
-We can use pragma Require to insure that checking occurs in the saturation
+We can use pragma Unsuppress to insure that checking occurs in the saturation
 multiply function given earlier:
 
      function "*" (Left, Right : Saturation_Type) return Saturation_Type is
-         pragma Require (Overflow_Check);
+         pragma Unsuppress (Overflow_Check);
      begin
          return Integer(Left) * Integer(Right);
      exception
@@ -104,6 +121,11 @@
              return Saturation_Type'Last;
      end "*";
 
+If there is a pragma Suppress for Overflow_Check effective in "*", the
+Unsuppress will revoke the permission to omit the checks, thus requiring the
+checks to be made. If there is no pragma Suppress, then the pragma Unsuppress
+is ignored.
+
 !discussion
 
 Ada 95 provides an easy way to suppress checking over large areas of
@@ -132,36 +154,68 @@
 compilers include an option switch that effectively adds pragma Suppress to
 the start of each compilation unit.
 
-The presence of pragma Require has no effect on compiler optimization of
+The presence of pragma Unsuppress has no effect on compiler optimization of
 checks. A compiler is still allowed to remove checks that it can prove will
-not fail.
+not fail. This is why the wording is expressed in terms of "revoking the
+permission to omit" rather than "requiring" checks.
 
-An early proposal called this pragma "Unsuppress". This name 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.
-
-This proposal does not allow suppressing checks inside of a checking required
-region. Such "resuppression" of checks could be supported, but does not seem
-important and would add implementation complexity (an implementation would need
-a stack of suppress and require pragmas). While it is possible for a programmer
-to require checks over an entire program, this is not the intended use of
-pragma Require. It is intended to be used in subprograms and blocks where
-checking is required.
-
-An implementation ought to display a warning if an attempt to give a pragma
-Suppress occurs in a region governed by a pragma Require for the same check,
-as the Suppress can have no effect.
+This proposal allows nested suppression of checks. That is, checks can be
+"resuppressed" inside of a region where checks are "unsuppressed" (required).
+This is necessary to prevent problems with code where the correctness depends
+on suppression of checks. (While such code is technically erroneous, in
+actual practice such does exist. We do not want to break it by being pedantic.)
+Such code would include a pragma Suppress. If checks could not be resuppressed,
+this code would fail if it was nested inside of a construct that contains
+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.
+
+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.
 
-Restrictions can be placed on pragma Require. This is necessary to avoid
+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 anything supported for Suppress is also
-supported for Require, because it is important to be able to "unsuppress"
+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 Require than of Suppress if they desire.
+implementations can support more of Unsuppress than of Suppress if they desire.
+
+Implementations should not produce warnings for usages of pragma Unsuppress
+which have no effect. (This is varies from common practice for other pragmas.)
+It is not an error to use a pragma Unsuppress where nothing is suppressed. Such
+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.
 
 !appendix
 
@@ -206,7 +260,7 @@
 Having the pragma have no effect in some circumstances might be a impediment
 to using it as a preventive, as a naive implementation of Ada might spew out
 a warning everytime such a pragma occurs. I don't think we can say "don't warn
-about this" in the reference manual, but without some guideance in this area,
+about this" in the reference manual, but without some guidance in this area,
 I can see implementors going through the RM and implementing each pragma in
 the "obvious" way [Janus/Ada, for instance, warns on any pragma that has no
 effect], which would be the wrong thing to do in this case.
@@ -220,7 +274,7 @@
 
 This is as far as I can tell exactly the same semantics as pragma
 Unsuppress in GNAT, and indeed these are the obvious semantics,
-since they derive directly from Supress.
+since they derive directly from Suppress.
 
 I see no point whatsoever in changing the name
 
@@ -294,7 +348,7 @@
 given precedence.>>
 
 I think this is a bad choice, I prefer everything to nest, so that you
-can nest Suppress/Unsupress to any depth, and the innermost one is
+can nest Suppress/Unsuppress to any depth, and the innermost one is
 what has the effect. This is the way GNAT works.
 
 *************************************************************
@@ -303,9 +357,9 @@
 Sent: Monday, November 22, 1999 9:41 PM
 
 incidentally, although I would argue for the more natural semantics that
-Suppress can undo Unsupress and vice versa to any depth, I don't really
+Suppress can undo Unsuppress and vice versa to any depth, I don't really
 care. It is obviously more work to implement Randy's suggested semantics,
-but in practice it is competely unimportant, the probability of ever
+but in practice it is completely unimportant, the probability of ever
 having more than one level of these pragmas is zero in any case.
 
 *************************************************************
@@ -416,7 +470,7 @@
 suppressed anywhere in your program.
 
 Why do I think that is a non-problem? Simply because I have never run into
-a customer requirement or an internal reqiurement for such a feature.
+a customer requirement or an internal requirement for such a feature.
 
 Unsuppress was put there solely for local control in situations which need
 local control. Thus the stacking semantics seems much more natural to me.
@@ -447,7 +501,7 @@
 Sunday from a week in the UK where those were some of the project's major
 topics, and some people walked away with bandaged fingers :). Incidently, this
 project does extremely heavy numeric calculations, numerical integrations of
-transendental functions, we do not suppress any checks, and performance is not
+transcendental functions, we do not suppress any checks, and performance is not
 an issue.
 
 The point is that Ada's loopholes are a real problem for real projects. We have
@@ -586,7 +640,7 @@
 a) I see no reason for such a restriction, the semantics is natural, a
 suppress cancels a previous unsuppress and vice versa.
 
-b) This is used in practice sometimes to just unsupress checks for an
+b) This is used in practice sometimes to just unsuppress checks for an
 individual statement or suppress them for an individual statement. Yes
 you could declare a block for this, but why require this.
 
@@ -634,11 +688,11 @@
 are used as configuration pragmas. We could prevent the use of Unsuppress as a
 configuration pragma, but this seems like an unnatural restriction.
 
->b) This is used in practice sometimes to just unsupress checks for an
+>b) This is used in practice sometimes to just unsuppress checks for an
 >individual statement or suppress them for an individual statement. Yes
 >you could declare a block for this, but why require this.
 
-Something is wrong with this. By 11.5(5), Suppress (and presumably Unsuppess) is
+Something is wrong with this. By 11.5(5), Suppress (and presumably Unsuppress) is
 only allowed in a declarative_part, package specification, or as a configuration
 pragma. That makes it impossible to use "around a statement" without an
 enclosing block.
@@ -746,7 +800,7 @@
 <<Have you considered making it implementation defined in that case?
 >>
 
-Sounds reaqsonable to me, it depends on which is processed last, which
+Sounds reasonable to me, it depends on which is processed last, which
 is indeed impl defined.
 
 *************************************************************
@@ -782,7 +836,7 @@
 
 (But of course the order is significant). This is what I use in release code
 where size is an issue: the only check that I find critical is Stack and Heap
-checking (because the results are so catastropic if they are omitted).
+checking (because the results are so catastrophic if they are omitted).
 
 I want to have a way to do this as a configuration pragma/option in any
 implementation that I'm using. Making it implementation-defined eliminates that
@@ -849,7 +903,7 @@
 wrong to warn unconditionally.
 
 For example, we generally compile the GNAT runtim elibrary with checks off
-(i.e. the eqiuvalent of a pragma Suppress at the configuration level).
+(i.e. the equivalent of a pragma Suppress at the configuration level).
 
 Individual little sections of the runtime that rely on checks (e.g. converting
 Constraint_Error into Time_Error in Calendar) do an Unsuppress.
@@ -884,7 +938,7 @@
 >
 > (But of course the order is significant). This is what I use in release code
 > where size is an issue: the only check that I find critical is Stack and
-> Heap checking (because the results are so catastropic if they are omitted).
+> Heap checking (because the results are so catastrophic if they are omitted).
 >
 > I want to have a way to do this as a configuration pragma/option in any
 > implementation that I'm using. Making it implementation-defined eliminates