CVS difference for ais/ai-00224.txt

--- ais/ai-00224.txt	2000/03/14 00:05:55	1.11
+++ ais/ai-00224.txt	2000/03/15 18:52:56	1.12
@@ -1478,3 +1478,736 @@
 
 *************************************************************
 
+From: Erhard Ploedereder
+Sent: Monday, March 13, 2000 7:33 PM
+
+Let me throw in a suggestion. Why not simply define Unsuppress without
+the On parameter? That way, all these nasty issues seem to be avoided.
+Yes, it's not quite so convenient, expressive, etc, etc, but it seems
+to avoid all the nastiness that you've been discussing.
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, March 14, 2000 6:58 AM
+
+<<To avoid that, we also have to avoid the following:
+
+     pragma Suppress (Access_Check); -- A configuration pragma.
+
+     pragma Suppress (Access_Check, On => Some_Type);
+     ...
+     pragma Unsuppress (Access_Check, On => Some_Type);
+
+     -- Is Access_Check suppressed here on Some_Type?
+>>
+
+Since people are trying to copy a well established and frequently used
+feature in GNAT, it may be useful to say what GNAT does :-)
+
+The way GNAT works is that a check is suppressed if
+
+EITHER it is scope suppressed OR (for some "appropriate" choice of entities
+to test) it is suppressed on a relevant entity.
+
+This means that the sequence above is well defined to suppress access checks
+on Some_Type in GNAT. I am not necessarily saying that is the way things
+should work, but this has a clear implementation model, and is also easy
+to describe.
+
+In other words, my suggestion is precisely, as in my previous message,
+that a pragma Unsuppress has ONLY the effect of cancelling the effects
+(whatever they migfht be) of a previous Suppress with the same entity.
+
+Thus the sequence above is equivalent to just the first pragma, and so
+the check is indeed suppressed.
+
+In fact as I think about it, I would recommend that this in fact be the
+defined semantics.
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, March 14, 2000 7:12 AM
+
+<<Let me throw in a suggestion. Why not simply define Unsuppress without
+the On parameter? That way, all these nasty issues seem to be avoided.
+Yes, it's not quite so convenient, expressive, etc, etc, but it seems
+to avoid all the nastiness that you've been discussing.
+>>
+
+I could buy this approach.
+
+I also think that my definition is viable. I will repeat it again.
+
+pragma Unsuppress with an entity has ONLY the effect of cancelling a
+previous Suppress applying to this same entity.
+
+If there is no such previous Suppress, then the pragma Unsuppress has
+no effect at all.
+
+*************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, March 14, 2000 9:16 AM
+
+This seems odd to me.  I would expect an Unsuppress...On to ensure
+that (unless overridden by a Suppress...On) the specified check
+would not be suppressed, even if there is a suppress-all somewhere
+in scope.
+
+But I also agree with Randy that we should try to find something
+we can all agree on.
+
+If we abandon the "Unsuppress...On" we will still need to define
+how Unsuppress relates to Suppress...On.
+
+Also, noone has addressed my concern about spec/body inheritance
+and stub/subunit inheritance, as it relates to source-wide
+configuration pragmas.
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, March 14, 2000 9:30 AM
+
+<<This seems odd to me.  I would expect an Unsuppress...On to ensure
+that (unless overridden by a Suppress...On) the specified check
+would not be suppressed, even if there is a suppress-all somewhere
+in scope.
+>>
+
+I explained why this is inherently non-portable. Let me try again.
+
+The RM has nothing to say, nothing at all, about WHICH entities are
+involved for consideration when considering whether to remove a given
+check.
+
+This means that the set of possibly erroneous programs is not very
+well defined, and is in fact implementation dependent. Trying to define
+this more specifically would be a horrible nightmare in my opinion.
+But in the case of Suppress it really does not matter, since if a given
+suppress has no effect, that is really not critically important, and
+programs should not rely on executing erroneous code (working correctly
+is an acceptable behavior for erroneous code in this case).
+
+But in the Unsuppress case, if you follow the semantics suggested by Tuck
+above, it then becomes critically important to determine which entities
+get tested (see my previous message for an example showing why this is
+hard to do).
+
+Yes, the above idea makes sense. No, it is not practical.
+
+If people share Tuck's reaction that my suggestion is odd, then the best
+remedy is to follow Erhard's idea and only allow pragma Unsuppress with
+no Entity argument (GNAT will of course continue to implement the full
+form, since we are not about to make incompatible changes here!)
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, March 14, 2000 11:19 AM
+
+Robert said:
+
+> > I also think that my definition is viable. I will repeat it again
+> >
+> > pragma Unsuppress with an entity has ONLY the effect of canceling a
+> > previous Suppress applying to this same entity.
+> >
+> > If there is no such previous Suppress, then the pragma Unsuppress has
+> > no effect at all.
+
+and Tucker replied:
+
+> This seems odd to me.  I would expect an Unsuppress...On to ensure
+> that (unless overridden by a Suppress...On) the specified check
+> would not be suppressed, even if there is a suppress-all somewhere
+> in scope.
+
+I discussed this in detail last night. (So much detail that most everyone seems
+to have glossed over it.) Robert's semantics are the only possible semantics
+that can be defined in a fully-implementation independent fashion.
+
+However, I objected to this semantics on a usage basis, as it makes it very
+difficult to write a bullet-proof subprogram that depends on checks being made
+(and exceptions raised).
+
+Thus, I proposed only defining Unsuppress without the On parameter, and
+including an implementation permission to allow implementations (such as GNAT)
+to support Unsuppress with an On parameter with implementation-defined
+semantics.
+
+> If we abandon the "Unsuppress...On" we will still need to define
+> how Unsuppress relates to Suppress...On.
+
+The only way for it to be useful is if it revokes the permissions on all
+Suppress...On. Otherwise, it can't be used to idiot-proof code that needs
+checking, and that is the use that needs to be defined portably. (I gave a
+concrete example of this last night.)
+
+> Also, no one has addressed my concern about spec/body inheritance
+> and stub/subunit inheritance, as it relates to source-wide
+> configuration pragmas.
+
+Not true. I commented on it originally, suggesting that we determine what
+existing implementations do here. (And opening a separate AI on the topic if
+people feel it is important enough, as it has little to do with Unsuppress.)
+Forcing implementations to inherit Suppress in bodies would be very bad *if*
+compilers aren't already doing it. I know Janus/Ada doesn't do it, but I don't
+know what other compilers do (which is more important).
+
+*************************************************************
+
+From: Ada Rapporteur Group of WG9; managing the Ada issues [ARG@ACM.ORG]
+on behalf of Tucker Taft [stt@averstar.com]
+Sent: Tuesday, March 14, 2000 10:39 AM
+To: ARG@ACM.ORG
+Subject: Re: AI 224 suppress/unsuppress details
+
+Robert Dewar wrote:
+>
+> <<This seems odd to me.  I would expect an Unsuppress...On to ensure
+> that (unless overridden by a Suppress...On) the specified check
+> would not be suppressed, even if there is a suppress-all somewhere
+> in scope.
+> >>
+>
+> I explained why this is inherently non-portable. Let me try again.
+
+I accept that it is harder to define the semantics.  By saying it is "odd"
+I meant that it would be unintuitive and potentially misleading for the
+user if Unsuppress...On did not in fact unsuppress a check.
+
+Given that, and your argument that the semantics are difficult to define,
+one could argue for discouraging the use of Unsuppress...On.  However,
+if GNAT continues to support it, then does that mean we should all feel free
+to support it in various non-portable ways?  My sense is that we should either
+*all* drop support for it, or include it with specifically implementation-defined
+semantics (perhaps deserving a warning?).
+
+*************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, March 14, 2000 12:51 PM
+
+Randy Brukardt wrote:
+>
+> Robert wrote:
+>
+> > One problem in general here is that while suppress has no semantics (since
+> > it can be ignored), unsuppress DOES have semantics. That means that the
+> > question unanswered in the RM:
+> >
+> > What exact entities should be tested for suppress to see if this check
+> > should be carried out?
+> >
+> > Has to be answered for unsuppress if you are not careful, and that way
+> > lies madness.
+>
+> Thanks for pointing this out. This point brings a whole different
+> perspective to this discussion.
+>
+> I agree with this point - that we have to avoid any semantics that requires
+> answering this question.
+
+I don't agree with the distinction between Suppress...On and
+Unsuppress...On as far as semantics (see below).
+
+>
+> More from Robert:
+>
+> > I think it is clear from both this definitional point of view, and from
+> > an implementation point of view that an unsuppress on a specific entity
+> > should only have the effect of canceling a previous suppress on that
+> > specific entity.
+> >
+> > Yes, it sounds useful to be able to do a general suppress, and then
+> > unsuppress on a specific entity, but this is simply not viable in
+> > practice, unless you want to leave things entirely implementation
+> > dependent.
+
+I don't understand this logic either.  Should a specific Suppress...On
+be able to override a non-specific Unsuppress?  If so, then the converse
+should work as well, in my view.
+
+> ...
+> If we had a piece of code where it is necessary to handle Ada exceptions, we
+> would want to be able to tell the compiler not to mess with it. A way to do
+> that with the proposal as defined in the AI would be to put a pragma
+> Unsuppress (Some_Check); into the code. The idea would be to prevent any
+> compiler options (or ham-handed maintenance programmer, for that matter)
+> from causing a subtle bug. For this use, it is critical that the meaning of
+> Unsuppress be well-defined.
+
+I don't see why Suppress...On need not be "well defined" whereas
+Unsuppress...On does need to be.  Suppress...On is stating "I know
+I never fail Blah_Check on blah object/subtype."  If this is misinterpreted
+to apply to some other object/subtype, where Blah_Check failures do
+occur and where exceptions should be raised, then this affects semantics
+just as much as a misinterpreted Unsuppress...On.
+
+I don't see any need to be more or less precise in Unsuppress...On than
+in Suppress...On (the problems that can occur seem to be essentially
+the same if the pragma is misinterpreted -- a check might get suppressed
+that in fact would fail in the given program).
+
+> ... I'm not sure it is worth
+> the effort to define the case where it does have to be *not* implementation
+> defined: (when the check and name of a single Suppress pragma conform), but
+> I will leave that to the rest of the ARG.
+
+I'm not sure why you talk about "conforming" here.  We are talking about
+entities, not expressions, so either they denote the same entity, or
+they don't.
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, March 14, 2000 1:41 PM
+
+<<I accept that it is harder to define the semantics.  By saying it is "odd"
+I meant that it would be unintuitive and potentially misleading for the
+user if
+Unsuppress...On did not in fact unsuppress a check.
+>>
+
+No more unintuitive than doing a Suppress on a given entity and finding
+out that it does not suppress the check. For example, in
+
+  A := B;
+
+where there is a tag check, GNAT checks the type involved, but not the
+class type, or any parent type, or the objects A and B, and indeed one
+customer recently was surprised that suppressing checks on A did not work.
+
+<<Given that, and your argument that the semantics are difficult to define,
+one could argue for discouraging the use of Unsuppress...On.  However,
+if GNAT continues to support it, then does that mean we should all feel free to
+support it in various non-portable ways?  My sense is that we should either
+*all* drop support for it, or include it with specifically
+implementation-defined semantics (perhaps deserving a warning?).
+>>
+
+Well I think it is a bit unrealistic to ask GNAT to unimplement anything.
+Why should we cause our customers incompatibility problems. I would
+certainly be willing to have this case included in the
+
+pragma Restrictions (No_Implementation_Pragmas)
+
+P.S. it would be nice to pseudo-standardize this restriction identifier
+
+The only time that GNAT unimplemented anything in the name of conformity
+was the handling of Call_By_Copy. This caused customers a LOT of problems,
+and if we knew what we did now, we would not repeat that experience.
+
+Yes, I know it is nice to be conformant, but I think this urge should be
+restricted to defining a subset that everyone will implement, not agitation
+to unimplement allowed extensions.
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, March 14, 2000 1:59 PM
+
+<<However, I objected to this semantics on a usage basis, as it makes it very
+difficult to write a bullet-proof subprogram that depends on checks being
+made (and exceptions raised).
+>>
+
+Now this must be wrong, *adding* a facility cannot make it harder to do
+something!
+
+Sure, to write bulletproof subprograms, you either
+
+a) know what the compiler does, and use the specific entity form, e.g. this
+is perfectly reasonable in the GNAT runtime, which has ZERO interest in
+running on other compilers, and is entirely GNAT specific.
+
+or (and we in fact prefer this in the GNAT runtime always :-)
+
+b) use the form with only a scope suppress
+
+I am not sure what you mean about "inherit suppress in bodies", but if
+it means what I think it means, I would consider a compiler that does not
+do this to be broken ... but perhaps I misunderstand.
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, March 14, 2000 2:12 PM
+
+I find Tuck's answer here insufficiently pragmatic, and it just does not
+seem worth the work to try to tune up this ill-advised, ill-defined
+feature in the RM (what precise entities are tested).
+
+I have no problem with deciding not to standardize the entity form of
+unsuppress. As I said before, GNAT does implement this form with very
+well defined semantics, as I noted. Yes, they are not as well defined
+as they might be, since the effect of the suppress is not well defined.
+
+I find it surprising that Tuck does not see the difference between
+suppress and unsuppress here!
+
+A suppress is never critical. Any code that relies on a suppress actually
+suppressing checks is clealry incorrect.
+
+An unsuppress is very often critical. Code very often relies on a check that
+is guaranteed to occur, regardless of compiler options, as a reuslt of
+ensuring that the check is not suppressed.
+
+That's a VERY big difference in practice.
+
+The point is that you cannot simply borrow the Suppress semantics (which are
+ill defined and non-portable, but it does not matter that much) for
+Unsuppress in a manner that leaves them as ill defined and non-portable
+(since it could matter a lot!)
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, March 14, 2000 3:32 PM
+
+> I'm not sure why you talk about "conforming" here.  We are talking about
+> entities, not expressions, so either they denote the same entity, or
+> they don't.
+
+Not really, there are whole can of worms here I would rather leave the lid on.
+For instance, are two subtypes of the same type the same or different entities
+for the purpose of suppressing checks? I'd just as soon let compilers do
+whatever they're going to do here.
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, March 14, 2000 3:53 PM
+
+> <<However, I objected to this semantics on a usage basis, as it makes it very
+> difficult to write a bullet-proof subprogram that depends on checks being
+> made (and exceptions raised). >>
+>
+> Now this must be wrong, *adding* a facility cannot make it
+> harder to do something!
+
+Robert, it's clear to me from your mail to Tucker that you understand the
+problem, so I think we're a lot closer together on this than is obvious.
+
+> Sure, to write bulletproof subprograms, you either
+>
+> a) know what the compiler does, and use the specific entity form, e.g. this
+> is perfectly reasonable in the GNAT runtime, which has ZERO interest in
+> running on other compilers, and is entirely GNAT specific.
+>
+> or (and we in fact prefer this in the GNAT runtime always :-)
+>
+> b) use the form with only a scope suppress
+
+Well, what I want to do is to bullet-proof my code against anything that a
+ham-handed maintenance programmer (which might be me!) or end-user (of Claw, for
+instance) might do.
+
+I certainly can't assume a specific compiler (rules out (a)), and I don't have
+any way to prevent someone from using Suppress (..., On => ...). I could imagine
+a compiler option that Suppressed checks on all entities whose names started
+with 'A'. (OK, I'm reaching here). But certainly a maintenance programmer could
+insert a Suppress (..., On => ...) for some reason, and my bullet-proof
+subprogram isn't bullet-proof anymore.
+
+The best way to support bullet-proof routines is for non-specific Suppress to
+force *all* of the appropriate checks on. This also has the least surprise for
+the user (because they actually get what they said -- does GNAT warn if a
+non-specific unsuppress is leaving some checks suppressed??). But I do see the
+definitional problem (although I really don't see why it is a problem to
+Unsuppress everything -- there can be no confusion as to what is unsuppressed in
+that case). [BTW, I don't think that changing GNAT to do just that (no other
+changes) would break user programs -- at worst they would get a bit more
+checking than expected in some subprogram.]
+
+I suppose another way out of this problem would be to adopt the GNAT semantics
+and to provide a Restictions identifier "No_Specific_Suppress" that I could use
+as a configuration pragma in Claw (or any other code that I needed to
+bullet-proof). The restriction would make any specific Suppress that reached a
+unit with the restriction illegal, as well as the use of it. (If the maintenance
+programmer then went ahead and removed that, well, there is only so much
+bullet-proofing that is possible...)
+
+> I am not sure what you mean about "inherit suppress in bodies", but if
+> it means what I think it means, I would consider a compiler that does not
+> do this to be broken ... but perhaps I misunderstand.
+
+Janus/Ada uses a purely textual model for controlling checks, inherited from our
+CP/M compilers. Anything that doesn't map cleanly into that is rejected, and
+many suppresses are in fact rejected (well, ignored with a warning). This area
+really deserves a rewrite (especially since the back-end will support a less
+restrictive model), but since we don't have any customers who've complained
+about that, it doesn't have much priority. And there would be compatibility
+problems with the old Janus/Ada specific check control pragmas...
+
+*************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, March 14, 2000 3:02 PM
+
+Robert Dewar wrote:
+> ...
+> I find it surprising that Tuck does not see the difference between
+> suppress and unsuppress here!
+>
+> A suppress is never critical. Any code that relies on a suppress actually
+> suppressing checks is clealry incorrect.
+>
+> An unsuppress is very often critical. Code very often relies on a check that
+> is guaranteed to occur, regardless of compiler options, as a reuslt of
+> ensuring that the check is not suppressed.
+>
+> That's a VERY big difference in practice.
+
+I still don't see this.  Consider the following:
+
+    A := B;  -- check cannot fail, would like to suppress it
+    C := D;  -- check failure possible at run-time; need to catch it
+
+Now if we use a Suppress...On to suppress the check on "A := B" and due
+to lack of precision it "spills over" into "C := D" then we have a
+serious problem.
+
+Similarly, if we use an Unsuppress...On to unsuppress the check on "C :=
+D" and due to lack of precision it doesn't override some more global Suppress,
+then we have a serious problem.
+
+These kinds of imprecision both seem just as bad.  An overeager Suppress...On
+is just as bad as a too-timid Unsuppress...On.  What am I missing?
+
+> The point is that you cannot simply borrow the Suppress semantics (which are
+> ill defined and non-portable, but it does not matter that much) for
+> Unsuppress in a manner that leaves them as ill defined and non-portable
+> (since it could matter a lot!)
+
+I suppose you could say that we need a portable *lower bound* on how
+much Unsuppress...On affects, and a portable *upper bound* on how much
+Suppress...On affects. Both bounds seem just as important.
+
+*************************************************************
+
+From: Robert A Duff
+Sent: Tuesday, March 14, 2000 4:37 PM
+
+> I suppose you could say that we need a portable *lower bound* on how
+> much Unsuppress...On affects, and a portable *upper bound* on how much
+> Suppress...On affects. Both bounds seem just as important.
+
+Perhaps, but neither one is terribly important.  I wrote the section on
+Suppress, and I spent some energy trying to nail down the rules, before
+I finally decided it was impractical, as Robert has pointed out.  Note
+that the Ada 83 RM didn't nail down the rules, either, but that fact was
+less clear.
+
+I would like to disallow Unsuppress...On, but Robert says GNAT will keep
+it (and I agree that ACT would be foolish to remove it at this point).
+Therefore, no matter what the ARG does, there *will* be Unsuppress...On,
+and it *will* be non-portable.  We should just live with that fact.
+
+The average user isn't going to understand some complicated set of rules
+about On=> (which leads to the same sort of bugs you mention above).  So
+why don't we just give up and say it's impl-def?  Is that so horrible?
+
+By the way, I don't really understand Randy's concern:
+
+> We distribute the Claw bindings as source code. We do this so customers can
+> recompile it on a new version of a compiler, or on a different compiler,
+> without have to depend on us to support it for them. Clearly, this means
+> that we have limited control over the compiler options used when compiling
+> the source. We want to make the source code as bullet-proof as possible,
+> because we don't want to have to spend lots of technical support time
+> tracking down problems. Thus, we try to write the code as generically as
+> possible, so that the choice of compiler options does not affect the code.
+
+Are you worried that *you* might put an outer Suppress...On in the code?
+Or are you worried that the customer might insert one?  If the former,
+my answer is, "Don't do that."  If the latter, my answer is that of
+course if users edit the sources they might break things.
+
+You're correct that Suppress...On is the tool of the devil.  It
+shouldn't be in the language in the first place.  But obviously we can't
+get rid of it now.  So just don't use it.
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, March 14, 2000 4:26 PM
+
+<<These kinds of imprecision both seem just as bad.  An overeager Suppress...On
+is just as bad as a too-timid Unsuppress...On.  What am I missing?
+>>
+
+You are inventing bugs, we are not talking about an over-eager suppress here,
+that would be a bug, bugs are a BAD THING, and must be avoided.
+
+We are talking about under-eager suppresses. For example:
+
+  A := B;
+
+if you suppress constraint check on A (or B) that might or might not
+suppress this check, it certainly WILL NOT suppress a check on C := D.
+
+But your code can never count on a suppress being effective anyway.
+
+On the other hand, if you have a scope suppress set, and you unsuppress
+on A and B, and expect this to make
+
+  A := B;
+
+not raise an exception, then the under-eager unsuppress WILL cause a
+problem.
+
+<<These kinds of imprecision both seem just as bad.  An overeager Suppress...On
+is just as bad as a too-timid Unsuppress...On.  What am I missing?
+>>
+
+The overeager Suppress is a pure invention, and nothing to do with anything
+we are discussing here.
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, March 14, 2000 4:41 PM
+
+<<I would like to disallow Unsuppress...On, but Robert says GNAT will keep
+it (and I agree that ACT would be foolish to remove it at this point).
+Therefore, no matter what the ARG does, there *will* be Unsuppress...On,
+and it *will* be non-portable.  We should just live with that fact.
+>>
+
+Seems reasonable to me ...
+
+<<The average user isn't going to understand some complicated set of rules
+about On=> (which leads to the same sort of bugs you mention above).  So
+why don't we just give up and say it's impl-def?  Is that so horrible?
+>>
+
+Incidentally, note that the GNAT rule is *very* easy to explain and for
+people to understand (the On form of Unsuppress does nothing but cancel
+the effects of an identical active Suppress ON, and if there is none,
+does nothing at all).
+
+<<Are you worried that *you* might put an outer Suppress...On in the code?
+Or are you worried that the customer might insert one?  If the former,
+my answer is, "Don't do that."  If the latter, my answer is that of
+>>
+
+I understand perfectly the concern here, and we have exactly the same
+effect in the GNAT runtime. You want to write code that can be compiled
+with checks on or checks off (compiler option) and stlil be functionally
+correct. This was the motivation for Unsuppress in the first place.
+
+Telling people "don't do that" is not an acceptable solution, and in any
+case it makes very good sense to suppress checks on the GNAT runtime, it
+removes almost all the checks (all but the very few that are functionally
+necessary and which are assured by Unsuppress).
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, March 14, 2000 5:46 PM
+Subject: RE: AI 224 suppress/unsuppress details
+
+<<Well, what I want to do is to bullet-proof my code against anything that a
+ham-handed maintenance programmer (which might be me!) or end-user (of Claw,
+for instance) might do.
+>>
+
+Well your maintenance programmer could be incompetent in many other ways,
+I don't see this as very convincing, but I understand your point.
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, March 14, 2000 5:47 PM
+
+<<Not really, there are whole can of worms here I would rather leave the lid
+on. For instance, are two subtypes of the same type the same or different
+entities for the purpose of suppressing checks? I'd just as soon let
+compilers do whatever they're going to do here.
+>>
+
+They are different entities, that's quite clear from the RM.
+
+*************************************************************
+
+From: Robert A Duff
+Sent: Tuesday, March 14, 2000 6:16 PM
+
+> Well, what I want to do is to bullet-proof my code against anything that a
+> ham-handed maintenance programmer (which might be me!) or end-user (of Claw,
+> for instance) might do.
+
+That's easy: a coding convention that says "don't use On =>".
+
+It seems sort of like you're worrying that somebody, somewhere, might do
+an Unchecked_Conversion that would violate the invariants of my package,
+and I want to protect my package from that.  Well, you can't, in Ada.
+
+*************************************************************
+
+From: Robert A Duff
+Sent: Tuesday, March 14, 2000 6:27 PM
+
+> Incidentally, note that the GNAT rule is *very* easy to explain and for
+> people to understand (the On form of Unsuppress does nothing but cancel
+> the effects of an identical active Suppress ON, and if there is none,
+> does nothing at all).
+
+And if it's also easy to implement, then I'm for it.
+
+My main concern here is that we don't cause a lot of implementation
+effort for these "On =>"'s, which are very close to being totally
+useless.
+
+> <<Are you worried that *you* might put an outer Suppress...On in the code?
+> Or are you worried that the customer might insert one?  If the former,
+> my answer is, "Don't do that."  If the latter, my answer is that of
+> >>
+>
+> I understand perfectly the concern here, and we have exactly the same
+> effect in the GNAT runtime. You want to write code that can be compiled
+> with checks on or checks off (compiler option) and stlil be functionally
+> correct. This was the motivation for Unsuppress in the first place.
+>
+> Telling people "don't do that" is not an acceptable solution, and in any
+> case it makes very good sense to suppress checks on the GNAT runtime, it
+> removes almost all the checks (all but the very few that are functionally
+> necessary and which are assured by Unsuppress).
+
+No, I think you miss Randy's point (as do I).  I agree with the above --
+that's exactly how I use pragma Unsuppress -- I want to have a run-time
+system that can be compiled with checks on or off (a global setting) and
+work either way.  So I mark parts of the code with pragma Unsuppress
+that I know really need the checks.  But I never seem to need "On =>".
+
+Randy, on the other hand, seems to be worried about an outer
+Suppress...On versus an inner Unsupress without On.  I'm not worried
+about customers who secretly add Suppress...On pragmas to key variables
+inside the run-time system, any more than I'm worried about customers
+who add any other kind of bug.
+
+You say, "it makes very good sense to suppress checks on the GNAT
+runtime", which I agree with.  But it doesn't make sense to add "pragma
+Suppress(Overflow_Check, On => The_Result_Of_The_Exponentiation_Op);" to
+some random part of the GNAT runtime.
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, March 14, 2000 7:16 PM
+
+<<You say, "it makes very good sense to suppress checks on the GNAT
+runtime", which I agree with.  But it doesn't make sense to add "pragma
+Suppress(Overflow_Check, On => The_Result_Of_The_Exponentiation_Op);" to
+some random part of the GNAT runtime.
+>>
+
+No, definitely not, and I am in agreement with the rest of Bob's coments as
+well here.
+
+*************************************************************
+