Version 1.8 of ais/ai-00257.txt

Unformatted version of ais/ai-00257.txt version 1.8
Other versions for file ais/ai-00257.txt

!standard 13.12.1 (01)          05-08-20 AI95-00257/05
!class amendment 01-02-12
!status Amendment 200Y 02-07-10
!status WG9 Approved 02-06-21
!status ARG Approved 9-0-0 01-10-07
!status work item 01-02-12
!status received 01-02-12
!priority Low
!difficulty Easy
!subject Restrictions for implementation-defined entities
!summary
The following restrictions identifiers exist:
No_Implementation_Attributes No_Implementation_Pragmas
!problem
Ada code containing implementation-defined attributes and pragmas is much less portable than code that does not contain such items. However, it is difficult to prove that a given piece of Ada code does not contain any implementation-defined items. This can be accomplished by searching for the name of each possible implementation-defined entity, but this is error-prone and can be very time consuming if an implementation has many implementation-defined items.
!proposal
We introduce additional restrictions identifiers to let the Ada processor do the checking for implementation-defined items.
The following restrictions identifiers are added:
No_Implementation_Attributes No_Implementation_Pragmas
These restrictions apply only to the current compilation or environment, not the entire partition; a partition may include compilations to which these restrictions do not apply.
!discussion
ARG approved amendments are considered "language-defined".
Some implementation-defined pragma arguments are common (for instance, the convention "StdCall" on Windows). If the No_Implementation_Pragmas applied to entire partitions, it would be impossible to use it on any program targeting Windows (as all of the system calls use "StdCall", not "C", and restrictions apply to the runtime library). More generally, it is often not useful to apply these restrictions to the runtime and user-written low-level packages. Therefore, these restrictions are defined to not apply to entire partitions.
!wording
The following restrictions identifiers are language-defined:
No_Implementation_Attributes
There are no implementation-defined attributes. This restriction applies only to the current compilation or environment, not the entire partition.
No_Implementation_Pragmas
There are no implementation-defined pragmas or pragma arguments. This restriction applies only to the current compilation or environment, not the entire partition.
!example
!corrigendum 13.12.1(01)
Insert new clause:
Static Semantics
The following restriction_identifiers are language-defined (additional restrictions are defined in the Specialized Needs Annexes):
No_Implementation_Attributes
There are no implementation-defined attributes. This restriction applies only to the current compilation or environment, not the entire partition.
No_Implementation_Pragmas
There are no implementation-defined pragmas or pragma arguments. This restriction applies only to the current compilation or environment, not the entire partition.
!ACATS test
B-Tests should be constructed to verify that these restrictions are enforced.
!appendix

From: Robert Dewar [dewar@GNAT.COM]
Sent: Tuesday, December 26, 2000 11:18 AM

Well a very important feature in GNAT that definitely should be
semi-standardized is

pragma Restrictions (No_Implementation_Attributes);

which would of course also disallow extensions to existing attributes

We also have

pragma Restrictions (No_Implementation_Pragmas);
pragma Restrictions (No_Implementation_REstrictions)

yes yes, I know the latter has to exclude itself :-)

****************************************************************

From: Pascal Leroy
Sent: Wednesday, December 27, 2000 4:53 AM

These sound like very good ideas.

****************************************************************

From: Robert A Duff
Sent: Tuesday, January 02, 2001 2:28 PM

Yes, that's a good idea.

Is it possible to turn it off in certain places?  I would like to be
able to say No_Implementation_Attributes on my whole program, but then
use impl-def attributes in one or two isolated places, by saying
"Yes_Implementation_Attributes" or some such thing in those places.

****************************************************************

From: Robert Dewar
Sent: Tuesday, January 02, 2001 3:26 PM

Actually perhaps the best idea is to generalize this thought for *all*
restrictions pragmas???

****************************************************************

From: Randy Brukardt
Sent: Tuesday, January 02, 2001 4:09 PM

Humm. Partition-wide restrictions make sense when they are used for runtime
tailoring (as suggested by Annex D), but when they are used to enforce
coding standards, certainly a method to allow exceptions would be very
valuable.

It is specifically this reason (that we *don't* want it to be
partition-wide) that the pragma Explicit_Overridding is not a Restrictions
identifier, but rather is a separate configuration pragma.

****************************************************************

From: Robert Dewar
Sent: Tuesday, January 02, 2001 7:00 PM

There is no requirement that restrictions pragmas have a partition wide
effect as a general rule.

****************************************************************

From: Robert Dewar
Sent: Tuesday, January 02, 2001 10:04 PM

I really don't understand the argument here, there is simply no requirement
that all restrictions be partition wide, so why on earth was this used
as an argument that explicit overriding ccould not be a restriction?

From the RM:

<<8   A pragma Restrictions is a configuration pragma; unless otherwise
specified for a particular restriction, a partition shall obey the
restriction if a pragma Restrictions applies to any compilation unit included
in the partition.>>

****************************************************************

From: Randy Brukardt
Sent: Tuesday, January 02, 2001 11:10 PM

You are quite right, I'm misremembering the RM here. Forget I brought up
that example.

Are there any Restrictions identifiers that aren't currently partition-wide?
I couldn't find one in a quick search of the RM.

In any case, the question is whether most of the restrictions defined in the
RM ought to have been partition-wide. It seems that they ought to be for
Annex D (for runtime selection), but not so obviously for Annex H or
"causal" use. And, if that decision was wrong, what we can do about it now?

****************************************************************

Questions? Ask the ACAA Technical Agent