Version 1.5 of ais/ai-00212.txt
!standard 10.01.05 (09) 02-10-23 AI95-00212/02
!class binding interpretation 99-03-26
!status Amendment 200Y 02-10-23
!status ARG approved 10-0-0 02-10-12
!status work item 00-11-13
!status received 98-11-21
!priority Low
!difficulty Medium
!qualifier Clarification
!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
(See Summary.)
!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.
!corrigendum 10.1.5(9)
Replace the paragraph:
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.
by:
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.
!ACATS test
Existing ACATS tests take advantage of this capability.
!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
<<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.
>>
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
<<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.
>>
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)).
****************************************************************
Questions? Ask the ACAA Technical Agent