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
!class amendment 99-11-19
!status work item 99-11-19
!status received 99-11-19
-!subject pragma Require
+!subject pragma Unsuppress
@@ -31,31 +31,32 @@
-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.
-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
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
+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
-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);
return Integer(Left) * Integer(Right);
@@ -104,6 +121,11 @@
+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
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. 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
+ 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.
@@ -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 @@
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
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
@@ -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
Questions? Ask the ACAA Technical Agent