CVS difference for ais/ai-00224.txt

--- ais/ai-00224.txt	1999/11/30 20:05:15	1.7
+++ ais/ai-00224.txt	1999/12/10 01:13:30	1.8
@@ -793,3 +793,112 @@
 
 *************************************************************
 
+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 ;-).
+
+*************************************************************
+