!standard 10.01.05 (09) 98-11-21 AI95-00212/00 !class confirmation 98-11-21 !status received 98-11-21 !priority Low !difficulty Medium !subject Restrictions on configuration pragmas. !summary 98-11-21 !question 98-11-21 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. !response 98-11-21 !appendix 98-11-21 **************************************************************** 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 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) should be revised to apply to all queuing polies (see suggested wording in E.4(15.a.1/1)). **************************************************************** ****************************************************************