CVS difference for ais/ai-00212.txt

Differences between 1.2 and version 1.3
Log of other versions for file ais/ai-00212.txt

--- ais/ai-00212.txt	2000/10/05 02:47:30	1.2
+++ ais/ai-00212.txt	2000/11/28 23:48:27	1.3
@@ -1,30 +1,82 @@
-!standard 10.01.05  (09)                               98-11-21  AI95-00212/00
-!class confirmation 98-11-21
+!standard 10.01.05  (09)                               00-11-13  AI95-00212/01
+!class binding interpretation 99-03-26
+!status work item 00-11-13
 !status received 98-11-21
 !priority Low
 !difficulty Medium
 !subject Restrictions on configuration pragmas.
 
-!summary 98-11-21
+!summary
 
-!question 98-11-21
+For configuration pragmas that select partition-wide or system-wide
+options, an implementation may impose the restriction that the pragma
+be given as a stand-alone pragma as per the Implementation Permission
+10.1.5(9). The implementation shall then also support confirming pragmas
+in individual compilations for the same partition or system.
 
+For other configuration pragmas, a restriction that requires the pragmas
+to be given as stand-alone pragmas, is not permitted.
+
+!question
+
 The permission 10.1.5(9) says
-"An implementation may place restrictions on configuration pragmas, so
-long as it allows them when the environment contains no library_items other
-than those of the predefined environment."
+  An implementation may place restrictions on configuration pragmas, so
+  long as it allows them when the environment contains no library_items other
+  than those of the predefined environment.
 
 Does this apply when a configuration pragma is used in a compilation with
 other units (which then only applies to those units)? A poll of Ada experts
 has turned up a widely varying difference of opinion.
 
-!response 98-11-21
+!recommendation
 
+For configuration pragmas that select partition-wide or system-wide
+options, an implementation may impose the restriction that the pragma
+be given as a stand-alone pragma as per the Implementation Permission
+10.1.5(9). The implementation shall then also support confirming pragmas
+in individual compilations for the same partition or system.
+
+For other configuration pragmas, a restriction that requires the pragmas
+to be given as stand-alone pragmas, is not permitted.
+
+!wording
+
+The Implementation Permission 10.1.5(9) should be replaced by the
+following text:
+  An implementation may require that configuration pragmas that select
+  partition-wide or system-wide options be compiled when the environment
+  contains no library_items other than those of the predefined environment.
+  In this case, the implementation must still accept configuration pragmas
+  in individual compilations that confirm the initially selected
+  partition-wide or system-wide options.
+
+!discussion
+
+It is a good documentation convention to include partition-wide
+configuration pragmas in each compilation unit whose proper
+functioning is dependent on the partition-wide option, e.g., a
+particular scheduling regime. This argues against the Implementation
+Permission of 10.1.5(9). However, without further restrictions, a
+link-time check is then required upon linking the units of a partition
+to ensure the consistency of the selected options. To the extent that
+partition-wide options imply different code generation, code may need
+to be (re)generated at link-time.
+
+It is also a good configuration management convention in environments that
+support separate libraries for separate partitions to "pre-configure" the
+library with the partition-wide option that will apply to all units compiled
+into the library. Here, enforcement of consistency and any impact on code
+generation can be accommodated at compile-time of the compilation units.
+
+The !recommendation reflects a compromise between these two positions,
+enabling both conventions to be applied by the user without mandating
+checks and possibly code generation at link-time.
+It also eliminates a portability problem with code that adheres to the
+documentation convention of including configuration pragmas with each
+unit that requires them.
 
-!appendix 98-11-21
+!appendix
 
-****************************************************************
-
 From: 	Tucker Taft[SMTP:stt@inmet.com]
 Sent: 	Wednesday, November 18, 1998 10:10 AM
 
@@ -191,12 +243,10 @@
 From: Randy Brukardt
 Sent: Thursday, August 31, 2000 6:06 PM
 
-The ARG ruled E.4(15) to be OK because of 10.1.5(9) makes it redundant (see
-AI-00069 & 8652/0116). If this AI removes/weakens 10.1.5(9), then E.4(15)
+The ARG ruled D.4(15) to be OK because of 10.1.5(9) makes it redundant (see
+AI-00069 & 8652/0116). If this AI removes/weakens 10.1.5(9), then D.4(15)
 should be revised to apply to all queuing polies (see suggested wording in
-E.4(15.a.1/1)).
+D.4(15.a.1/1)).
 
 ****************************************************************
 
-
-****************************************************************

Questions? Ask the ACAA Technical Agent