!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 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. 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. !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 From: Tucker Taft[SMTP:stt@inmet.com] Sent: Wednesday, November 18, 1998 10:10 AM > Depends on how you view the purpose of validation. If it is to ensure a > higher degree of portability, such tests would be of rather marginal value. > Reason: RM 10.1.5(9), which in effect is saying: "You want it portable, you > have to provide the Restrictions pragma before all other compilations of the > partition." and hence, testing more than that won't help portability. Even with 10.1.5(9), there is still justification for having configuration pragmas in a source file that has one or more compilation units. 10.1.5(9) was intended to apply only to pragmas in unitless source files, I believe. > Erhard -Tuck **************************************************************** From: Robert Dewar[SMTP:dewar@gnat.com] Sent: Friday, November 20, 1998 9:21 AM I agree with Tuck's assessment. **************************************************************** From: Randy Brukardt[SMTP:Randy@rrsoftware.com] Sent: Friday, November 20, 1998 2:01 PM Tucker says: >Even with 10.1.5(9), there is still justification for having configuration >pragmas in a source file that has one or more compilation units. >10.1.5(9) was intended to apply only to pragmas in unitless source files, >I believe. While I agree with Tucker's assessment, I find this last statement a bit hard to swallow. I can't imagine what benefit there would be to allowing the rejection of some environment-wide restrictions pragmas, while requiring them on specific compilation units. The final effect is the same: the partition as a whole most obey the restriction. And the implementation is the same. Certainly, the wording of 10.1.5(9) does not to restrict its applicability to certain cases, it applies to any use of a restrictions pragma. OTOH, if this is the accepted meaning (and I think that the ARG would need to discuss that), that makes it much easier to revise the tests to include link-time checks. With the current "optional" meaning, I don't think we want to change the existing tests, as doing so would compromise coverage of the checking for the various restrictions. In that case, adding a few .DEP tests would be the best solution. If, however, 10.1.5(9) is ruled not to apply to restrictions pragmas, then the best solution is to modify the existing tests. Randy. **************************************************************** From: Erhard Ploedereder[SMTP:ploedere@informatik.uni-stuttgart.de] Sent: Friday, November 20, 1998 10:09 PM >Even with 10.1.5(9), there is still justification for having configuration >pragmas in a source file that has one or more compilation units. >10.1.5(9) was intended to apply only to pragmas in unitless source files, >I believe. I figured I let this rest, since it seemed that we had reached a point of simply agreeing that we disagree, all being "right" from some valid viewpoint. But, as Randy picks it up again, let me chime in by saying that I couldn't find a shred of evidence in the RM or AARM that >10.1.5(9) was intended to apply only to pragmas in unitless source files. I guess it very much depends on the environment model that an implementation has, whether or not the link-time check is a good model to support. If the environment "forces" a separation of units destined for a single partition into a single "sub"environment, then that support seems totally useless -- I might as well provide my config pragmas first. If, on the other hand, the units of multiple partitions are compiled into a single otherwise unstructured environment, from which multiple partitions are later linked, then this support makes sense, I suppose. Erhard **************************************************************** From: Robert Dewar[SMTP:dewar@gnat.com] Sent: Friday, November 20, 1998 6:06 PM <> It is definitely important to be able to include configuration pragmas, not all of which are partition wide, to individual units of a program. **************************************************************** From: Robert Dewar[SMTP:dewar@gnat.com] Sent: Friday, November 20, 1998 9:09 PM Replying to Erhard, we have: 9 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. Now what does this mean about configuration pragmas that are placed as part of a unit. Does it mean this unit can only be compiled into an empty environment? If so, that's odd, note in particular that there are configuration pragmas that are NOT required to apply to the whole partition. If the implementation works by taking config pragmas from such a unit and making them apply to the parition, it had better be careful to make the necessary distinction between those that apply to a full partition anmd those that do not! I think it is much more natural to read para 9 as Tuck did! **************************************************************** From: Erhard Ploedereder[SMTP:ploedere@informatik.uni-stuttgart.de] Sent: Saturday, November 21, 1998 10:43 AM > 9 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. I simply read this as: It is legitimate to place the restrictions that a) configuration pragmas must be stand-alone units; and b) they must be compiled into the environment as the first units. That plays back the minimum capability required by the Standard. Anything more is optional. So, to answer your question: > Now what does this mean about configuration pragmas that are placed as > part of a unit. Easy. They violate the above restriction. Erhard **************************************************************** From: Robert Dewar[SMTP:dewar@gnat.com] Sent: Saturday, November 21, 1998 9:50 AM < Now what does this mean about configuration pragmas that are placed as > part of a unit. Easy. They violate the above restriction. >> I do not believe that this can possibly have been the intention, I guess the ARG will have to discuss this. **************************************************************** From: Randy Brukardt Sent: Thursday, August 31, 2000 6:06 PM 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 D.4(15.a.1/1)). ****************************************************************