Version 1.8 of ais/ai-00224.txt

Unformatted version of ais/ai-00224.txt version 1.8
Other versions for file ais/ai-00224.txt

!standard 11.5(1-8)          99-11-19 AI95-00224/01
!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
!summary
A pragma is introduced to require checking in a declarative region, irrespective of the use of pragma Suppress.
!problem
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:
function "*" (Left, Right : Saturation_Type) return Saturation_Type is begin
return Integer(Left) * Integer(Right);
exception
when Constraint_Error =>
return Saturation_Type'Last;
end "*";
This function will not work properly without overflow checking. Ada 95 does not provide a way to indicate this to the compiler and programmers.
!proposal
A new pragma Require is defined.
pragma Require (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.
Pragma Require means that the given check must be performed.
!wording
Define "Checking pragmas" and add pragma Require 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.
Add pragma Require to 11.5(3-4):
The forms of checking pragmas are as follows:
pragma Require(identifier [, [On =>] name]); pragma Suppress(identifier [, [On =>] name]);
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:
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.
Change 11.5(8) to define the meaning of pragma Require:
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, but not for any entity to which a pragma Require applies. 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.
!example
We can use pragma Require 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);
begin return Integer(Left) * Integer(Right); exception when Constraint_Error => return Saturation_Type'Last; end "*";
!discussion
Ada 95 provides an easy way to suppress checking over large areas of program text. Pragma Suppress can be used in a package specification to apply to an entire package, or even as a configuration pragma to apply to the entire program.
It is common for production versions of applications to be delivered with checking suppressed (perhaps for better performance or smaller code size). If pragma Suppress is applied to an entire package or program, code that requires checking will start to fail. Ada code that depends on the canonical checking semantics is not common, but it occurs frequently enough that most Ada programmers have been bitten by this problem at one time or another.
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 individual packages and/or subprograms, which is clearly error-prone.
The pragma proposed here can be used both as a preventative measure (to insure that the code continues to work if a later programmer applies Suppress to the unit) and as a repair when checks are suppressed where they are required.
Note that the pragma Suppress that causes problems may not be explicit; many 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 checks. A compiler is still allowed to remove checks that it can prove will not fail.
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.
Restrictions can be placed on pragma Require. 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" 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.
!appendix

*************************************************************

From: Randy Brukardt
Sent: Friday, November 19, 1999 7:34 PM

I've created this AI based on the discussion at the last ARG meeting.

I made one major change: based on the problem statement, the name "Unsuppress"
is the wrong name. In its intended use, we do not necessarily know that a
pragma Suppress has been applied to a region. Therefore, I renamed the pragma
to the more meaningful name "Require". I expect to catch some flak for this.

I find the preventative use of Require quite important, and quite in keeping
with the philosophy of Ada (make sure problems don't happen in the first
place).

It seems wrong to use a hypothetical pragma Unsuppress as a preventative: it
isn't undoing anything! Indeed, Ada users could imagine that it isn't allowed
unless there is a Suppress pragma to undo, and in that case, they would not
use it as a preventative.

I wonder if this entire clause shouldn't be renamed; it now is more about
controlling checks than about suppressing them.

One interesting issue: should pragma Require be allowed as a configuration
pragma? I have left it in, as that would allow effectively preventing the
adding of any pragma Suppresses to a program. That might be useful to some
paranoid organization. It also takes more words to disallow it than to allow
it.

Another interesting issue: should we allow "resuppression" of checks? I don't
feel strongly either way, but selected the current write-up because it was
more natural for pragma Require. The only way I see to support "resuppression"
is to write paragraph 8 in terms of "revoking the permission" to suppress
checks, which would complicate the description and would fit a pragma named
Unsuppress much better. It would also mean that a pragma Require would be
meaningless as a configuration pragma, as it would have no effect.

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,
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.

                        Randy.

*************************************************************

From: Robert Dewar
Sent: Monday, November 22, 1999 1:58 PM

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.

I see no point whatsoever in changing the name

a) People are used to pragma Unsuppress and are using it now

b) the name is FAR more obvious, Require?? Require what? Sure you could
make the same question for Suppress, but we know suppress already.

I would strongly oppose changing the name, and most certainly we will not
implement it under the name Require in GNAT, because this would be unnecessary
duplication.

*************************************************************

From: Randy Brukardt
Sent: Monday, November 22, 1999 7:16 PM

> 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 Suppress.

No, not exactly. The GNAT documentation that Ed handed out says "If there is no
corresponding pragma Suppress in effect, it [Unsuppress] has no effect." The
natural (to me) wording changes ended up with slightly different semantics, that
is that Suppress has no effect in a region where Require is given. The
difference is that Require can be given first -- it essentially is which is
given precedence.

> I see no point whatsoever in changing the name
>
> a) People are used to pragma Unsuppress and are using it now
>
> b) the name is FAR more obvious, Require?? Require what? Sure you could
> make the same question for Suppress, but we know suppress already.

Require the argument, just like Suppress is "Suppress the argument". I.e.

     pragma Require (Overflow_Check);

> I would strongly oppose changing the name.

OK, fair enough. In that case, I think that the answers to the two questions I
posed (does the pragma have an effect if no Suppress has been given, and should
"resuppression" be supported) should be different. And the pragma then has no
use as a preventative measure (both because it makes no sense to "Unsuppress" if
nothing is "Suppress"ed, and because a normally correct implementation of Ada 95
will complain about such pragmas).

> and most certainly we will not implement it under the name Require in GNAT,
> because this would be unnecessary duplication.

Well, this sounds very much like a Jean Ishbiah temper-tantrum: "If I can't have
my way, I'm going to take my ball and go home." I don't think this attitude is a
way to get useful work done (or to sway technical differences of opinion,
either). In any case, GNAT /= Ada. We want new features in Ada to be as useful
as possible to all users of Ada, not just to the customers of one particular
compiler.

			Randy.

*************************************************************

From: Robert Dewar
Sent: Monday, November 22, 1999 9:40 PM

<<No, not exactly. The GNAT documentation that Ed handed out says "If there is
no corresponding pragma Suppress in effect, it [Unsuppress] has no effect."
The natural (to me) wording changes ended up with slightly different semantics,
that is that Suppress has no effect in a region where Require is given. The
difference is that Require can be given first -- it essentially is which is
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
what has the effect. This is the way GNAT works.

*************************************************************

From: Robert Dewar
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
care. It is obviously more work to implement Randy's suggested semantics,
but in practice it is competely unimportant, the probability of ever
having more than one level of these pragmas is zero in any case.

*************************************************************

From: Randy Brukardt
Sent: Monday, November 22, 1999 10:12 PM

I agree that it doesn't matter much (the AI says as much).

I'm surprised that you say it would "obviously" take more work. I can see it
taking the same amount of work, but I don't see how it could take more. Indeed,
I would think it could take less work, because a stack isn't necessary to handle
it.

If others think it would take more work in their compilers, I'll junk the whole
AI and start over (the wording and discussion would have to be totally rewritten
to use a stacking semantics).

				Randy.

*************************************************************

From: John Barnes
Sent: Tuesday, November 23, 1999 4:37 AM

I don't  like the word Require either. It's a perfectly good word that
might be useful elsewhere whereas Unsuppress is a nasty word that is
most unlikely to be confused with anything else.

I would like to feel that the words have some symmetry.

John

*************************************************************

From: Stephen Michell
Sent: Tuesday, November 23, 1999 7:19 AM

John Barnes wrote:

> I don't like the word Require either. It's a perfectly good word that
> might be useful elsewhere whereas Unsuppress is a nasty word that is
> most unlikely to be confused with anything else.
>

An excellent point. Then Ada could be the language with the nastiest keywords
in town. No one would DARE critisize us then (at least - not to our faces).

> I would like to feel that the words have some symmetry.
>

It does seem clear that "unsuppress" is now in current usage and in the
lexicon of the community, so that is the way it must remain. It is also clear
to me that one can never permanently override the effects of the other, once
it has been selected.

It may be reasonable, however, to create a pragma "require" that is a
configuration pragma. Such a pragma couldn't override pragma suppress in code,
it would just fail the compile. That could be a useful way of ensuring that
there are no checks suppressed in your 5 million line program.

  ...stephen

*************************************************************

From: Robert Dewar
Sent: Tuesday, November 23, 1999 8:28 AM

Obviously the non-nesting semantics would take more work in GNAT, since it
is already done using stacking semantics. That was what I meant. We
implemented the stacking semantics because it seems clearly preferable.

*************************************************************

From: Robert Dewar
Sent: Tuesday, November 23, 1999 8:27 AM

I find a stacking semantics far more natural here, and in fact the more
I think about it, the more I think your non-stacking semantics is
fundamentally flawed.

If I write a little section of code which depends on correctness on the
fact that checks are suppressed, say for performance reasons in the
context of a particular compiler, it should not be possible to destroy
the correctness of this code by nesting it within a construct that contains
an Unsuppress and knows nothing about the code nested within it.

*************************************************************

From: Robert Dewar
Sent: Tuesday, November 23, 1999 8:38 AM

One more point on stacking semantics

It seems clear to me that Suppress and Unsuppress should be symmetrical
in their semantics. Anything else would be a surprise.

Given that it seems clear that a higher level Suppress cannot mask a lower
level Unsuppress, indeed in some sense that's the whole point of Unsuppress
(to undo a higher level Suppress).

So it would indeed seem odd if a Suppress cannot undo the effect of a higher
level Unsuppress.

I think part of the problem here is that Randy may have been trying to solve
a problem that Unsuppress is definitely NOT intended to address, and one
which to me is a non-problem, namely trying to ensure that checks are not
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.

Unsuppress was put there solely for local control in situations which need
local control. Thus the stacking semantics seems much more natural to me.

*************************************************************

From: Robert Dewar
Sent: Tuesday, November 23, 1999 8:18 AM

<<It may be reasonable, however, to create a pragma "require" that is a
configuration pragma. Such a pragma couldn't override pragma suppress in code,
it would just fail the compile. That could be a useful way of ensuring that
there are no checks suppressed in your 5 million line program.
>>

This seems overkill to me, I am really not aware of any requirements here.
After all Ada is full of deliberate loopholes to get around "checks",
most notably unchecked conversion and address clauses, why get all
upset about some local use of Suppress?

*************************************************************

From: Stephen Michell
Sent: Tuesday, November 23, 1999 11:33 AM

  Sure, and the first thing that real projects do is write coding standards that
break peoples' fingers if they dare use one of those. Just ask me - I came back
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
an issue.

The point is that Ada's loopholes are a real problem for real projects. We have
to do a lot of work to make sure that they are not used. Sure one can build
external tools to check for such things, but then one could code on C and rely
on external tools - right? Our community believes that the compilation
environment is the best line of defence for these issue, so let's seriously
consider ones that provide a real benefit.

A thought - The Annex H "pragma Restrictions" is helpful for many of the
significant issues, such as No_Allocation, No_Unchecked_Conversion, but
"no_pragma_suppress" is not one of the restrictions. Maybe that is the solution.

*************************************************************

From: Randy Brukardt
Sent: Tuesday, November 23, 1999 2:02 PM

> I find a stacking semantics far more natural here, and in fact the
> more I think about it, the more I think your non-stacking semantics
> is fundamentally flawed.
>
> If I write a little section of code which depends on correctness on
> the fact that checks are suppressed, say for performance reasons in
> the context of a particular compiler, it should not be possible to
> destroy the correctness of this code by nesting it within a construct
> that contains an Unsuppress and knows nothing about the code nested
> within it.

I find this a pretty compelling argument in practice (even though a
"correct" program can't depend on Suppress). I couldn't think of a case
where it would matter when I wrote the AI.

I've thought about it some more, and while the "stacking" semantics is easy to
describe informally, a formal description seems difficult. I don't think that
any of the existing Ada pragmas work this way (can anyone think of a
counter-example)? Any suggestions of how to word this? All I can think of is
"revoking the permission to suppress checks", but that is a double negative.

I'll rewrite the AI and repost it sometime after Thanksgiving.

				Randy.

*************************************************************

From: Randy Brukardt
Sent: Tuesday, November 23, 1999 2:45 PM

> I think part of the problem here is that Randy may have been trying to solve
> a problem that Unsuppress is definitely NOT intended to address, and one
> which to me is a non-problem, namely trying to ensure that checks are not
> suppressed anywhere in your program.

Well, actually, I was trying to provide a way to insure (typically in a local
section of code) that checking *is* done. That's because the person who writes
the code is lot more likely to know the requirements of the code. That has to
work no matter what configuration pragmas, compiler options, or whatever happen.
"Unsuppress" seems to be the wrong name for this purpose, because it does not
necessarily have anything to do with a Suppress. (I can live with it though).

The non-stacking part came from two issues: the difficulty of writing wording to
explain stacking formally, and to give meaning to the pragma when given as a
configuration pragma. (Remember that Suppress can be a configuration pragma).
The GNAT Unsuppress appears to be always ignored when given as a configuration
pragma. I'm not very excited about requiring compilers to implement a pragma
that will always be ignored.

An interesting question: if both a Suppress and Unsuppress are given in the same
scope, what happens? Does the order matter. For instance,

       procedure ...
           pragma Suppress (All_Checks);
           pragma Unsuppress (Storage_Check);

Does this Suppress all checks except Storage_Check?

       procedure ...
           pragma Unsuppress (Storage_Check);
           pragma Suppress (All_Checks);

Does this Suppress all checks including Storage_Check?

The problem is that configuration pragmas really don't have an order, so we
can't tell which came first. If the meaning depends in the order that they're
seen in, then using both Suppress and Unsuppress as configuration pragmas is
implementation-dependent. Ugh.

			Randy.

*************************************************************

From: Jean-Pierre Rosen
Sent: Wednesday, November 24, 1999 1:44 AM

> I've thought about it some more, and while the "stacking" semantics is easy
> to describe informally, a formal description seems difficult. I don't think
> that any of the existing Ada pragmas work this way (can anyone think of a
> counter-example)? Any suggestions of how to word this? All I can think of is
> "revoking the permission to suppress checks", but that is a double negative.
>
What's the problem ? The pragma applies to the declarative region where it
appears. In the case of nesting, the innermost wins.
Just state that you cannot have a suppress and an unsuppress in the same
declarative region for the same check (on the same object).
This is the natural Ada semantics.

*************************************************************

From: Robert I. Eachus
Sent: Friday, November 26, 1999 4:24 PM

I personally would find a non-stacking version of Unsuppress to be a problem,
even if it is never used in a stacking situation.  This is for code verification
reasons.  With the GNAT version, you just have to look at the closest nested
pragma, and if it matters to the logic of the code, the author will located it
as close as possible to the affected code to make verification easy.

Also, in the case of generics and in-line code, the fact that the code depended
on exceptions would need to be made visible to the user.

                                        Robert I. Eachus

*************************************************************

From: Robert Dewar
Sent: Monday, November 29, 1999 5:09 AM

<<In the case of nesting, the innermost wins.
Just state that you cannot have a suppress and an unsuppress in the same
declarative region for the same check (on the same object).
This is the natural Ada semantics.
>>

We don't have any such restriction in GNAT, and

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
individual statement or suppress them for an individual statement. Yes
you could declare a block for this, but why require this.

It would require extra mechanism to enforce such a restriction, since
it would mean that you not only have to have a flag indicating the
restriction, but also another flag indicating whether it was explicitly
set in the current scope.

*************************************************************

From: Randy Brukardt
Sent: Monday, November 29, 1999 9:55 AM

>Jean-Pierre says:

> What's the problem ? The pragma applies to the declarative region where it
> appears.

How do you describe what Unsuppress does??? In this semantics, it doesn't do
anything by itself. It can only be described in terms of some (outer?) Suppress;
which leads to the double negative wording.

> In the case of nesting, the innermost wins.
> Just state that you cannot have a suppress and an unsuppress in the same
> declarative region for the same check (on the same object).

Given that the language-defined checks include some that overlap (the obvious
one is All_Checks and everything else), this could be quite difficult to do.

> This is the natural Ada semantics.

Yes, if you make that restriction. But the restriction isn't natural, and it
isn't easy to describe.

---

>Robert Dewar says:

>We don't have any such restriction in GNAT, and

>a) I see no reason for such a restriction, the semantics is natural, a
>suppress cancels a previous unsuppress and vice versa.

I agree, except that the "order" of the pragmas is not well-defined when they
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
>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
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.

>It would require extra mechanism to enforce such a restriction, since
>it would mean that you not only have to have a flag indicating the
>restriction, but also another flag indicating whether it was explicitly
>set in the current scope.

Right. Plus you would have to deal with overlapping checks like All_Checks.

But without the restriction, it takes a lot more words to describe what happens.
This appears to be a case of "we know what we want, but we don't know how to
describe it".

			Randy.

*************************************************************

From: Tucker Taft
Sent: Monday, November 29, 1999 10:48 AM

Randy mentioned some concern about Unsuppress used as a configuration
pragma, as it seemed useless with the "stacking" interpretation.
However, if we consider a command-line parameter as the "outermost"
level, then a library-wide configuration pragma, then a compilation-wide
configuration pragma, then a scope-specific pragma, it seems like
configuration pragmas would fit into the "stacking" hierarchy in
a reasonable way.

For example, if you gave a "suppress-all" on the command line, but
had an Unsuppress for tag check in a library-wide configuration pragma,
that would seem meaningful and perhaps useful.

*************************************************************

From: Robert Dewar
Sent: Monday, November 29, 1999 9:12 PM

I definitely agree, we have seen this standard and useful application of
Unsuppress used, and use it ourselves sometimes.

*************************************************************

From: Randy Brukardt
Sent: Monday, November 29, 1999 1:31 PM

Tucker says:

> For example, if you gave a "suppress-all" on the command line, but
> had an Unsuppress for tag check in a library-wide
> configuration pragma, that would seem meaningful and perhaps useful.

Yes, but the problem is that it has been suggested that the order that
Suppress and Unsuppress pragmas is significant. That is,

   pragma Suppress (All_Checks);
   pragma UnSuppress (Overflow_Check);

(which suppresses all but Overflow_Check) means something different than

   pragma UnSuppress (Overflow_Check);
   pragma Suppress (All_Checks);

(which suppresses all checks), the UnSuppress being ignored.

The problem is that configuration pragmas are not given in a clearly defined
order. Since they can be compiled separately, and compilation order is not an
Ada 95 concept, the pragmas could occur in either order or simultaneously.
Similarly, we cannot say that compiler options occur before or after "real"
configuration pragmas. So how do we determine which of these are meant?

This means that the definition of configuration pragmas cannot depend on the
order of appearance. Yet, I've been told to write wording for UnSuppress which
*does* depend on the order that the pragmas appear. So, we have a problem.

If we get rid of the significance of the order (at least within a single scope),
we get rid of the problem, but that the cost of complicating things (and I
suspect that Robert won't go along with any such semantics). [That is, in a
scope, UnSuppress has precedence over Suppress.] We could also prevent multiple
pragmas in the same scope, but that is a problem because of overlapping sets of
checks. Or we could simply eliminate UnSuppress as a configuration pragma, which
would prevent the problem from occurring. None of these look like particularly
good choices.

			Randy.

*************************************************************

From: Robert A Duff
Sent: Monday, November 29, 1999 4:03 PM

> The problem is that configuration pragmas are not given in a clearly defined
> order.

Have you considered making it implementation defined in that case?

- Bob

*************************************************************

From: Robert Dewar
Sent: Monday, November 29, 1999 9:45 PM

<<Have you considered making it implementation defined in that case?
>>

Sounds reaqsonable to me, it depends on which is processed last, which
is indeed impl defined.

*************************************************************

From: Randy Brukardt
Sent: Monday, November 29, 1999 6:48 PM

Not seriously. That seems like a last resort: punt! Such a definition would
not be useful to people who need portable code, and of course would be
untestable.

*************************************************************

From: Robert Dewar
Sent: Monday, November 29, 1999 10:16 PM

Don't dance on pin heads :-)

Who cares if there are multiple conflicting pragmas in the configuration
pragmas, this simply won't happen in practice. Don't undermiune the
utility of USEFUL applications by worrying about things that are useless!

*************************************************************

From: Randy Brukardt
Sent: Tuesday, November 30, 1999 11:10 AM

I would agree, except that multiple conflicting pragmas are USEFUL: they provide
an easy way to turn off all but one check:

    pragma Suppress (All_Checks);
    pragma Unsuppress (Storage_Check);

(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).

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
possibility (unless all of the vendors support it in the same way, which is very
unlikely).

			Randy.

*************************************************************

From: Tucker Taft
Sent: Tuesday, November 30, 1999 3:59 PM

Randy Brukardt wrote:
>
> > > The problem is that configuration pragmas are not given in a clearly defined
> > > order.
> >
> > Have you considered making it implementation defined in that case?
>
> Not seriously. That seems like a last resort: punt! Such a definition would
> not be useful to people who need portable code, and of course would be
> untestable.

I would make it well defined if the configuration pragmas are all
in the same file (i.e., the last one applies).  If the
configuration pragmas are in separate files, then it is implementation-defined
what order these end up in when conceptually combined.  They
will be combined in some order, so there are a finite number of
distinct orders possible, and so it is testable.

If a programmer wants portability, they would put all the
configuration pragmas in the same file.

Hence, if they wanted to suppress everything but tag_check, they
could write:

    pragma Suppress(All_Checks);
    pragma Unsuppress(Tag_Check);

That seems pretty intuitive.

*************************************************************

From: Ted Baker
Sent: Tuesday, November 30, 1999 7:07 PM

After hearing a lot of talk on this one, I believe that as a user I would
view the nesting of Suppress and Unsuppress pragmas as unwise,
and so would  prefer for an implementation to at least give a
warning when this occurs.

However, if nesting is allowed, the innermost nested region should
certainly retain the effect of the pragma given for that region.

*************************************************************

From: Robert Dewar [dewar@GNAT.COM]
Sent: Tuesday, November 30, 1999 7:30 PM

YOu don't want a warning for all cases of nesting, otherwise every use
of Unsuppress in a typically suppressed region would generate a warning.
Since this kind of use is the principle utility o Unsuppress, it seems
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).

Individual little sections of the runtime that rely on checks (e.g. converting
Constraint_Error into Time_Error in Calendar) do an Unsuppress.

*************************************************************

From: Robert Dewar
Sent: Tuesday, November 30, 1999 5:40 PM

<<I would make it well defined if the configuration pragmas are all
in the same file (i.e., the last one applies).  If the
configuration pragmas are in separate files, then it is implementation-defined
what order these end up in when conceptually combined.  They
will be combined in some order, so there are a finite number of
distinct orders possible, and so it is testable.
>>

I agree with this, and cannot imagine that it in fact does not hold already
for all existing compilers.

*************************************************************

From: Tucker Taft
Sent: Thursday, December 02, 1999 10:23 AM

Randy Brukardt wrote:
> I would agree, except that multiple conflicting pragmas are USEFUL: they
> provide an easy way to turn off all but one check:
>
>     pragma Suppress (All_Checks);
>     pragma Unsuppress (Storage_Check);
>
> (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).
>
> 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 possibility (unless all of the vendors support it in the same way,
> which is very unlikely).

I trust you received the earlier message where this would be well-defined
if they are all in the same compilation.  If the configuration pragmas
are in separate (unit-less) compilations, then the order in which the
configuration pragmas are combined is implementation-defined (or perhaps
even "unspecified").  That would seem to address your concern.
In general, having multiple unit-less compilations with configuration
pragmas is a bit confusing anyway, I would say (though our front end
supports it ;-).

*************************************************************


Questions? Ask the ACAA Technical Agent