CVS difference for ais/ai-00224.txt

--- ais/ai-00224.txt	2003/03/04 04:56:21	1.26
+++ ais/ai-00224.txt	2003/05/24 00:51:35	1.27
@@ -1,4 +1,4 @@
-!standard 11.5(1)                                    03-02-17  AI95-00224/08
+!standard 11.5(1)                                    03-05-22  AI95-00224/09
 !standard 11.5(3)
 !standard 11.5(4)
 !standard 11.5(5)
@@ -19,8 +19,13 @@
 
 !summary
 
-A pragma is introduced to require checking in a declarative region,
-irrespective of the use of pragma Suppress.
+Pragma Unsuppress is introduced to revoke the permission to omit checks given
+by pragma Suppress. This pragma restores canonical checking semantics in a
+declarative region, irrespective of the use of pragma Suppress.
+
+The On parameter of pragma Suppress is moved to "Obsolescent Features", as
+there is no clear definition (or agreement) on its meaning, such a definition
+is needed in order to define the meaning of pragma Unsuppress.
 
 !problem
 
@@ -30,7 +35,7 @@
 
      function "*" (Left, Right : Saturation_Type) return Saturation_Type is
      begin
-         return Integer(Left) * Integer(Right);
+         return Saturation_Type (Integer(Left) * Integer(Right));
      exception
          when Constraint_Error =>
              return Saturation_Type'Last;
@@ -56,7 +61,7 @@
 Define "Checking pragmas" and add pragma Unsuppress to 11.5(1)
 ("Checking pragmas" is in italics):
 
-*Checking pragmas* give an implementation instructions on handling
+*Checking pragmas* give instructions to an implementation 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.
@@ -87,7 +92,8 @@
 declarative_part or immediately within a package_specification applies from the
 place of the pragma to the end of the innermost enclosing declarative region.
 The region for a checking pragma given as a configuration pragma is the
-declarative region for the entire compilation unit to which it applies.
+declarative region for the entire compilation unit (or units) to which it
+applies.
 
 [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
@@ -100,7 +106,7 @@
 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
+instantiation or call 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
@@ -176,15 +182,15 @@
 subtype, on objects and values of its type. A specific Suppress pragma
 suppresses the named check for any entities to which it applies (see 11.5).
 Which checks are associated with a specific entity is not defined by this
-standard.
+International Standard.
 
-AARM Discussion: Exactly which entit(ies) control whether a check is performed
-is not specified by the language. For example, in
+AARM Discussion: The language doesn't specify exactly which entities control
+whether a check is performed. 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.
+omit the range check.
 
                          Implementation Permissions
 
@@ -192,7 +198,7 @@
 
 Note
 
-An implementation may support an entity parameter on pragma Unsuppress (see
+An implementation may support a similar On parameter on pragma Unsuppress (see
 11.5).
 
 
@@ -231,7 +237,7 @@
 
 The problem is made worse by the fact that Ada 95 does not provide any
 way to turn off pragma Suppress over a smaller, inner region of the program.
-Therefore, fixing the problem requires moving the pragma Suppresses to
+Therefore, fixing the problem requires moving the Suppress pragmas to
 individual packages and/or subprograms, which is clearly error-prone.
 
 The pragma proposed here can be used both as a preventative measure (to
@@ -260,8 +266,8 @@
 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
+this code would fail if it were nested inside of a construct that contains
+an Unsuppress pragma, or if an 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.
 
@@ -277,10 +283,10 @@
 We considered eliminating inheritance from all of these programs, as it is
 preferable that a checking pragma be visible in any scope to which it applies.
 However, this is incompatible with both the existing language, and some
-existing implementation.
+existing implementations.
 
 We also considered having Unsuppress not inherit, while leaving Suppress alone.
-This has the unfortunate property of having too different models for the
+This has the unfortunate property of having two different models for the
 pragmas. This means that checking can change simply by moving code, as in the
 following example:
 
@@ -293,7 +299,7 @@
 In this model, Tag_Checks are suppressed in Proc depending on whether Proc
 is "inlined" into the package or separate.
 
-A third alternative is to simply define inheritance to be
+A third alternative considered was to simply define inheritance to be
 implementation-defined. This was rejected due to the lack of portability
 and that it leaves the language no safer than the existing inheritance model.
 
@@ -320,10 +326,10 @@
 
 Pragma (2) clearly occurs after the pragma Unsuppress, so the Unsuppress has
 no effect, and the check is suppressed. By the equivalence model, pragma (1)
-is equivalent to pragma (1).
+is equivalent to pragma (2).
 
 It is important to note that pragma Unsuppress has no effect of its own. There
-only is a permission to omit checks or no permission to do. Essentially,
+only is a permission to omit checks or no permission to do so. Essentially,
 an implementation which does not inherit the permission will always make the
 checks. This is identical to an implementation which does inherit the
 permission in the case when it is revoked (because then the checks are
@@ -343,30 +349,32 @@
 to change their inheritance semantics in order to implement Unsuppress.
 
 
-If more than one checking pragma is given as configuration pragmas, the
+If several checking pragmas are given as configuration pragmas, the
 language does not specify the order in which they are applied. This means that
 the exact effect is unspecified as well (as the order of the pragmas could
 change their effect). Consider:
+
     pragma Suppress (All_Checks);
     pragma Unsuppress (Storage_Check);
 vs.
     pragma Unsuppress (Storage_Check);
     pragma Suppress (All_Checks);
-Whether or not Storage_Check is suppress depends on the order of the pragmas.
+
+Whether or not Storage_Check is suppressed depends on the order of the pragmas.
 This doesn't seem to be an important enough problem to worry about; Unsuppress
 should be used in local scopes, not as a configuration pragma.
 
 
 Restrictions can be placed on pragma Unsuppress. This is necessary to avoid
-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
+burdening implementations by requiring the implementation of items for which
+no Suppress support is provided. We do require that any check names supported
+for Suppress are 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
+Checking pragmas with an On parameter are moved to the obsolescent features
 section. That was done because these features are inherently non-portable, and
 we want to discourage their use.
 
@@ -374,21 +382,22 @@
 Suppress vary widely, even for implementations with the same target. It does not
 seem valuable to try to bring any portability to this area.
 
-For instance, exactly which entit(ies) control when a check is performed
+For instance, exactly which entities 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
-on A, B, or the type of A. For check suppression, this is not critical, as
-any code that would violate the checks is erroneous anyway (11.5(26)). On
-the other hand, not making a check that the programmer is depending on can
-cause the program to fail. But what should be Unsuppressed in the above
-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.
+whether the range check is performed may depend on whether checks are
+suppressed on A, B, or the type of A. For check suppression, this is not
+critical, as any code that would violate the checks is erroneous anyway
+(11.5(26)). On the other hand, not making a check that the programmer is
+depending on can cause the program to fail. But what should be unsuppressed in
+the above 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.
 
 We do want to allow implementations to support pragma Unsuppress with an
 On parameter if they support pragma Suppress with an On parameter. This
-requires a specific permission, as implementations are not allowed to extend
-language-defined pragmas.
+requires a specific permission, as implementations are not otherwise allowed
+to extend language-defined pragmas.
 
 A benefit to making On parameters obsolescent is that this also signals
 implementors to spend little or no effort in this area, and users to not
@@ -396,7 +405,7 @@
 
 
 Implementations should not produce warnings for usages of pragma Unsuppress
-which have no effect. (This is varies from common practice for other pragmas.)
+which have no effect. (This 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.
@@ -412,7 +421,7 @@
 A @fa<pragma> Suppress gives permission to an implementation to omit certain
 language-defined checks.
 @dby
-@i<Checking pragmas> give an implementation instructions on handling
+@i<Checking pragmas> give instructions to an implementation on handling
 language-defined checks. A @fa<pragma> Suppress gives permission to an
 implementation to omit certain language-defined checks, while a @fa<pragma>
 Unsuppress revokes the permission to omit checks.
@@ -475,13 +484,13 @@
 @fa<declarative_part> or immediately within a @fa<package_specification>
 applies from the place of the @fa<pragma> to the end of the innermost enclosing
 declarative region. The region for a checking pragma given as a configuration
-pragma is the declarative region for the entire compilation unit to which it
-applies.
+pragma is the declarative region for the entire compilation unit (or units) to
+which it applies.
 
 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.
+a subprogram that has a @fa<pragma> Inline applied to it, then the checking
+pragma also applies to the inlined subprogram body.
 
 A @fa<pragma> Suppress gives permission to an implementation to omit the named
 check (or every check in the case of All_Checks) for any entities to which it
@@ -492,8 +501,8 @@
 every check in the case of All_Checks) given by any @fa<pragma> Suppress that
 applies at the point of the @fa<pragma> Unsuppress. The permission is revoked
 for the region to which the @fa<pragma> Unsuppress applies. If there is no such
-permission at the point of a @fa<pragma> Unsuppress, then the pragma has no
-effect. A later @fa<pragma> Suppress can renew the permission.
+permission at the point of a @fa<pragma> Unsuppress, then the @fa<pragma> has
+no effect. A later @fa<pragma> Suppress can renew the permission.
 
 !corrigendum 11.5(27)
 
@@ -511,7 +520,7 @@
 an unspecified subset of the Range_Checks.
 
 An implementation may support an additional parameter on @fa<pragma> Unsuppress
-similar to the one allowed for pragma Suppress (see J.10). The meaning of
+similar to the one allowed for @fa<pragma> Suppress (see J.10). The meaning of
 such a parameter is implementation-defined.
 
 !corrigendum 11.5(29)
@@ -556,15 +565,15 @@
 subtype, on objects and values of its type. A specific Suppress @fa<pragma>
 suppresses the named check for any entities to which it applies (see 11.5).
 Which checks are associated with a specific entity is not defined by this
-standard.
+International Standard.
 
 @i<@s8<Implementation Permissions>>
 
 An implementation is allowed to place restrictions on specific Suppress @fa<pragma>s.
 
 @xindent<@s9<NOTES@hr
-3 An implementation may support an entity parameter on @fa<pragma> Unsuppress (see
-11.5).>>
+3 An implementation may support a similar On parameter on @fa<pragma> Unsuppress
+(see 11.5).>>
 
 !ACATS Tests