!standard 13.12 (07) 01-06-04 AI95-00257/02 !class amendment 01-02-12 !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. It can be accomplished by searching for the names 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 do not apply to partitions; a partition may include compilations to which these restrictions do not apply. !discussion ARG approved amendments are considered "language-defined". If a user wishes to avoid depending on amendments, they should use pragma Feature (see AI-222) or other facilities defined by the implementation for that purpose. 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 does not apply to partitions; a partition may include some compilations to which this restrictions apply and some to which this restriction does not apply. No_Implementation_Pragmas There are no implementation-defined pragmas or pragma arguments. This restriction does not apply to partitions; a partition may include some compilations to which this restrictions apply and some to which this restriction does not apply. !example !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? ****************************************************************