!standard 13.12(1) 11-06-09 AI05-0246-1/05 !standard 13.12(9.2/1) !standard 13.12.1(2/2) !standard 13.12.1(8/2) !standard D.13(1/2) !standard D.13(2/2) !standard D.13(3/2) !standard D.13(4/2) !standard D.13(5/2) !standard D.13(6/2) !class Amendment 11-03-16 !status Amendment 2012 11-05-02 !status ARG Approved 8-0-0 11-04-07 !status work item 11-02-19 !status received 11-02-19 !priority Medium !difficulty Easy !subject Restriction No_Implementation_Identifiers and Profile No_Implementation_Extensions !summary Add a new restriction No_Implementation_Identifiers to disallow use of implementation-defined identifiers from language-defined units. Also add a new profile No_Implementation_Extensions that is equivalent to the set of restrictions of the form No_Implementation_*. !problem It is easy for a programmer to use unintentionally an implementation-defined identifier in a language-defined unit. Package System is the most common culprit, but uses of identifiers like Short_Short_Integer from package Standard, identifiers in package Interfaces, etc., can also create portability problems. It would be useful if there were a way to ensure at compile-time that there are no uses of implementation-defined declarations. Going further, it would be nice if there were a way to specify no dependence on implementation-defined constructs with a single Profile. !proposal Add a restriction No_Implementation_Identifiers which disallows use of implementation-defined identifiers in language-defined packages. This includes identifiers in Standard, System, and Command_Line, as well as any uses of declarations in Ada.Interrupts.Names, Interfaces, and the Implementation subpackages of the Queue containers. !wording Change name of 13.12 from "Pragma Restrictions" to "Pragma Restrictions and Pragma Profile" Modify 13.12(1) as follows: [Redundant: A pragma Restrictions expresses the user's intent to abide by certain restrictions. {A pragma Profile expresses the user's intent to abide by a set of Restrictions or other specified run-time policies.} [This]{These} may facilitate the construction of simpler run-time environments.] Move content of D.13 to after 13.12(9.2/1): Syntax The form of a pragma Profile is as follows: pragma Profile (/profile_/identifier {, /profile_/pragma_argument_association}); Legality Rules The /profile_/identifier shall be the name of a [run-time]{usage} profile. The semantics of any /profile_/pragma_argument_associations are defined by the [run-time]{usage} profile specified by the /profile_/ identifier. Static Semantics A profile is equivalent to the set of configuration pragmas that is defined for each [run-time]{usage} profile. Post-Compilation Rules A pragma Profile is a configuration pragma. There may be more than one pragma Profile for a partition. Change name of "13.12.1 Language-Defined Restrictions" to "13.2.1 Language-Defined Restrictions and Profiles" Add after 13.12.1(2/2): No_Implementation_Identifiers There are no usage names that denote declarations with implementation-defined identifiers that occur within language-defined packages. [Redundant: Such identifiers can arise as follows: * The following language-defined packages allow implementation-defined identifiers: - package System (see 13.7); - package Standard (see A.1); - package Ada.Command_Line (see A.15); - package Interfaces.C (see B.3); - package Interfaces.C.Strings (see B.3.1); - package Interfaces.C.Pointers (see B.3.2); - package Interfaces.COBOL (see B.4); - package Interfaces.Fortran (see B.5). * The following language-defined packages contain only implementation-defined identifiers: - package System.Machine_Code (see 13.8); - package Ada.Directories.Information (see A.16); - nested Implementation packages of the Queue containers (see A.18.28-31); - package Interfaces (B.2); - package Ada.Interrupts.Names (see C.3.2). ] For package Standard, Standard.Long_Integer and Standard.Long_Float are considered language-defined identifiers, but identifiers such as Standard.Short_Short_Integer are considered implementation-defined. This restriction applies only to the current compilation or environment, not the entire partition. Add after 13.2.1(8/2): The following /profile_/identifier is language-defined: No_Implementation_Extensions For usage profile No_Implementation_Extensions, there shall be no /profile_/pragma_argument_associations. The No_Implementation_Extensions usage profile is equivalent to the following restrictions: No_Implementation_Aspect_Specifications, No_Implementation_Attributes, No_Implementation_Identifiers, No_Implementation_Pragmas, No_Implementation_Units. Renumber "D.13.1 Ravenscar Profile" to be "D.13 Ravenscar Profile" Modify D.13.1 (now D.13) paragraphs 2/2 and 3/2 as follows: The /profile_/identifier Ravenscar is a [run-time]{usage} profile. For [run-time]{usage} profile Ravenscar, there shall be no /profile_/pragma_argument_associations. The [run-time]{usage} profile Ravenscar is equivalent to the following set of pragmas: !discussion The goal of this AI is to complete the set of No_Implementation_* portability restrictions, and add a Profile that combines them all. Package System seems to be the primary culprit in unintentional non-portabilities created by references to implementation-defined declarations. But there are other packages with similar issues, and we have tried to provide the complete set here. Note that No_Implementation_Aspect_Specifications and No_Implementation_Units come from AI05-0241-1 and AI05-0242-1, respectively, and as such, if they are not approved, they should be dropped from the wording above. We have moved the definition of pragma Profile up into the core part of the standard, so it can be used for things other than tasking-related profiles. We have renamed "run-time profiles" to be "usage profiles" to reflect their broader applicability. We originally considered changing the implementation advice about providing Long_Integer and Long_Float into implementation requirements, but the advice is already pretty strong, in that implementations are required to document why they don't follow advice. This seems adequate for these two. We do specifically indicate that Long_Integer and Long_Float are language-defined identifiers, while Short_Short_Integer, etc. are not. !example pragma Profile(No_Implementation_Extensions); !corrigendum 13.12(1) @drepl A pragma Restrictions expresses the user's intent to abide by certain restrictions. This may facilitate the construction of simpler run-time environments. @dby A pragma Restrictions expresses the user's intent to abide by certain restrictions. A pragma Profile expresses the user's intent to abide by a set of Restrictions or other specified run-time policies. These may facilitate the construction of simpler run-time environments. !corrigendum 13.12(9.2/1) @dinsa Whenever enforcement of a restriction is not required prior to execution, an implementation may nevertheless enforce the restriction prior to execution of a partition to which the restriction applies, provided that every execution of the partition would violate the restriction. @dinss @i<@s8> @xindent Profile is as follows:> @xindent<@b Profile (@i@fa {, @i@fa});> @i<@s8> The @i@fa shall be the name of a usage profile. The semantics of any @i@fas are defined by the usage profile specified by the @i@fa. @i<@s8> A profile is equivalent to the set of configuration pragmas that is defined for each usage profile. @i<@s8> A @fa Profile is a configuration pragma. There may be more than one @fa Profile for a partition. !corrigendum 13.12.1(2/2) @dinsa @xhang<@xterm There are no implementation-defined attributes. This restriction applies only to the current compilation or environment, not the entire partition.> @dinss @xhang<@xterm There are no usage names that denote declarations with implementation-defined identifiers that occur within language-defined packages. Such identifiers can arise as follows:> @xbullet @xinbull @xinbull @xinbull @xinbull @xinbull @xinbull @xinbull @xinbull @xbullet @xinbull @xinbull @xinbull @xinbull @xinbull @xindent @xindent !corrigendum 13.12.1(8/2) @dinsa No compilation unit included in the partition shall depend semantically on the library unit identified by the @fa. @dinss @i<@s8> The following @i@fa is language-defined: @xhang<@xterm> For usage profile No_Implementation_Extensions, there shall be no @i@fas. The No_Implementation_Extensions usage profile is equivalent to the following restrictions: @xcode !corrigendum D.13(1/2) @drepl This clause specifies a mechanism for defining run-time profiles. @dby This clause defines the Ravenscar profile. !corrigendum D.13(2/2) @ddel @xindent Profile is as follows:> !corrigendum D.13(3/2) @ddel @xindent<@b Profile (@i@fa {, @i@fa});> !corrigendum D.13(4/2) @drepl The @i@fa shall be the name of a run-time profile. The semantics of any @i@fas are defined by the run-time profile specified by the @i@fa. @dby The @i@fa Ravenscar is a usage profile (see 13.12). For usage profile Ravenscar, there shall be no @i@fas. !corrigendum D.13(5/2) @drepl A profile is equivalent to the set of configuration pragmas that is defined for each run-time profile. @dby The usage profile Ravenscar is equivalent to the following set of pragmas: @xcode<@b Task_Dispatching_Policy (FIFO_Within_Priorities); @b Locking_Policy (Ceiling_Locking); @b Detect_Blocking; @b Restrictions ( No_Abort_Statements, No_Dynamic_Attachment, No_Dynamic_Priorities, No_Implicit_Heap_Allocations, No_Local_Protected_Objects, No_Local_Timing_Events, No_Protected_Type_Allocators, No_Relative_Delay, No_Requeue_Statements, No_Select_Statements, No_Specific_Termination_Handlers, No_Task_Allocators, No_Task_Hierarchy, No_Task_Termination, Simple_Barriers, Max_Entry_Queue_Length =@> 1, Max_Protected_Entries =@> 1, Max_Task_Entries =@> 0, No_Dependence =@> Ada.Asynchronous_Task_Control, No_Dependence =@> Ada.Calendar, No_Dependence =@> Ada.Execution_Time.Group_Budget, No_Dependence =@> Ada.Execution_Time.Timers, No_Dependence =@> Ada.Task_Attributes, No_Dependence =@> System.Multiprocessors.Dispatching_Domains);> @s8<@i> A task shall only be on the ready queues of one processor, and the processor to which a task belongs shall be defined statically. Whenever a task running on a processor reaches a task dispatching point, it goes back to the ready queues of the same processor. A task with a CPU value of Not_A_Specific_CPU will execute on an implementation defined processor. A task without a CPU pragma will activate and execute on the same processor as its activating task. @s8<@i> On a multiprocessor system, an implementation should support a fully partitioned approach. Each processor should have separate and disjoint ready queues. !corrigendum D.13(6/2) @drepl A @fa Profile is a configuration pragma. There may be more than one @fa Profile for a partition. @dby @xindent<@s9 1 restriction applies only to protected entry queues due to the accompanying restriction of Max_Task_Entries =@> 0.>> !ACATS test Add a ACATS B test for this feature. !ASIS No ASIS effect (Restrictions and Profiles are not handled specially by ASIS). !appendix From: Randy Brukardt Sent: Wednesday, March 16, 2011 8:44 PM The one thing that worries me about version /01 of this AI is changing the clause number of the Ravenscar profile stuff. I don't know how many error messages point there (as opposed to the constituent restrictions), but it seems like there could be quite a few, and as such it seems dubious. Of course you are right that the entire profile thing ought to have been declared in 13.12 in the first place, but I wonder if we should just leave D.13 as essentially empty in order to avoid changing the unrelated D.13.1. **************************************************************** From: Tucker Taft Sent: Wednesday, March 16, 2011 9:06 PM This seems like a lousy reason to leave the manual incorrectly organized. Also, GNAT doesn't use RM clause numbers very often in their error messages, and since they are probably the only compiler that has implemented the Ravenscar profile at this point, it doesn't seem like a big deal. **************************************************************** From: Randy Brukardt Sent: Wednesday, March 16, 2011 9:16 PM I admit that part of the reason I don't like this reorganization is that I don't have any way to change a subclause to a clause in the current RM tools, and I can't quite imagine one that would make any sense whatsoever. Maybe something will come to mind, but most likely we'd have to abandon the capability of generating older standards completely. (I've occasionally used that to improve the HTML that is available on-line for the older standards.) Not a big deal; I'm more concerned about unnecessary changes that might affect users. (We've already had one complaint about the way we renumbered the containers packages, and I can't quite figure out why anyone would care for predefined packages.) **************************************************************** From: Edmond Schonberg Sent: Wednesday, March 16, 2011 9:19 PM Furthermore, errors on some violation of a profile point to the configuration file that names the profile, and not to the RM at all, so this is a non-issue in the case of GNAT. **************************************************************** From: John Barnes Sent: Thursday, April 7, 2011 6:36 AM What a weird hotchpotch of things restricted in No_Implementation_Identifiers * There are no usage names that denote declarations with implementation-defined identifiers that occur within: - package Standard (see A.1), - package System (see 13.7), or - package Ada.Command_Line (see A.15); * There are no usage names that denote declarations that occur within: - package Ada.Interrupts.Names (see C.3.2), - package Interfaces (B.2), or - nested Implementation packages of the Queue containers (see A.18.28-31). Where is the justification for this mixture? I am amazed. **************************************************************** From: Randy Brukardt Sent: Monday, April 18, 2011 10:43 PM > What a weird hotchpotch of things restricted in > > No_Implementation_Identifiers As noted during the phone call, this is intended to list all of the places that implementation-defined identifiers are allowed in language-defined packages. > * There are no usage names that denote declarations with > implementation-defined identifiers that occur within: > - package Standard (see A.1), > - package System (see 13.7), or > - package Ada.Command_Line (see A.15); > > * There are no usage names that denote declarations that occur within: > - package Ada.Interrupts.Names (see C.3.2), > - package Interfaces (B.2), or > - nested Implementation packages of the Queue containers (see A.18.28-31). I'm wondering why this second list does not include System.Machine_Code (13.8(5-6)). Whatever contents it has must be implementation-defined, but the package name itself is language-defined. I suppose we could consider this package to be implementation-defined (since it is optional), but if so we ought to have an AARM note to mention this fact. Ada.Directories.Information is another similar package; that one is only defined by Implementation Advice (A.16(142/2)) so it more clearly appears to be impldef -- but even so there is an argument that it too is language-defined. Tucker didn't mention in the !discussion if he left these out on purpose, or whether he just didn't notice them. Thoughts? **************************************************************** From: Tucker Taft Sent: Monday, April 18, 2011 11:10 PM ... > Tucker didn't mention in the !discussion if he left these out on > purpose, or whether he just didn't notice them. Just an oversight. **************************************************************** From: Randy Brukardt Sent: Monday, April 18, 2011 11:30 PM OK, I added System.Machine_Code to the list. (Still waiting on the intro sentence from Tucker on this AI, too.) Any thoughts as whether to include Ada.Directories.Information here?? **************************************************************** From: Tucker Taft Sent: Monday, April 18, 2011 11:46 PM Yes, I think so. Ada.Directories.Information is listed in the set of Language-Defined Library Units in A.0(2/3), so we should put it with the other packages that are unmentionable under the No_Implementation_Identifiers restriction. **************************************************************** From: Randy Brukardt Sent: Tuesday, April 19, 2011 12:12 AM Good point. I'm surprised to find it in A(2/3), and I *wrote* that. (Which proves something, but I'm not sure exactly what. :-) I've added it to the AI. Now about that introduction line... **************************************************************** From: Robert Dewar Sent: Tuesday, April 19, 2011 3:34 AM Why should this restriction worry about packages, when packages are more usefully restricted using No_Dependence? **************************************************************** From: Tucker Taft Sent: Tuesday, April 19, 2011 7:18 AM The point was to have a single restriction that eliminated all references to identifiers that were implementation-defined, appearing within language-defined packages. If that is all of the identifiers within the package, so be it. It also future-proofs the program, so as new packages are added to the language, they will be automatically covered as appropriate. Finally, it means that the profile No_Implementation_Extensions is easy to define, as the union of the No_Implementation_* restrictions. **************************************************************** From: Tucker Taft Sent: Tuesday, April 19, 2011 2:16 PM This AI has been largely reworded in the section on No_Implementation_Identifiers, and the aspect names in No_Implementation_Extensions have been alphabetized. The point of the rewording was to make the main rule that there would be no use of impl-defined identifiers that occur in lang-defined packages, and then put the particular package names into "Redundant" []. [This is version /02 of the AI - Editor.] **************************************************************** From: John Barnes Sent: Wednesday, April 20, 2011 2:01 AM > This AI has been largely reworded in the section > on No_Implementation_Identifiers, and the aspect > names in No_Implementation_Extensions have been > alphabetized. Which has the advantage that the ugly long one is now first and doesn't (seem to) stick out so much. Mumble, mumble said Robert. **************************************************************** From: Randy Brukardt Sent: Thursday, June 9, 2011 7:37 PM AI05-0246-1 says in part: No_Implementation_Identifiers There are no usage names that denote declarations with implementation-defined identifiers that occur within language-defined packages. [Redundant: Such identifiers can arise as follows: * The following language-defined packages allow implementation-defined identifiers: - package System (see 13.7); - package Standard (see A.1); - package Ada.Command_Line (see A.15). * The following language-defined packages contain only implementation-defined identifiers: - package System.Machine_Code (see 13.8); - package Ada.Directories.Information (see A.16); - nested Implementation packages of the Queue containers (see A.18.28-31); - package Interfaces (B.2); - package Ada.Interrupts.Names (see C.3.2). I was reading Interfaces.Fortran for unrelated reasons, and noticed B.5(21): "An implementation may add additional declarations to the Fortran interface packages. ..." I'm not sure why this is plural (there is only one Interfaces.Fortran package), but in any case it sounds like this is a "language-defined package that allows implementation-defined identifiers". Similarly for Interfaces.C (permission B.3(62), which also seems to apply to Interfaces.C.Strings and Interfaces.C.Pointers), and the more specific permissions B.4(92-93), which apply to Interfaces.COBOL. Since we are already mentioning Interfaces, it seems we need to mention these other packages as well. So I propose that we add: - package Interfaces.C (see B.3); - package Interfaces.C.Strings (see B.3.1); - package Interfaces.C.Pointers (see B.3.2); - package Interfaces.COBOL (see B.4); - package Interfaces.Fortran (see B.5). at the end of the existing list. I'll modify AI-0246-1 this way unless someone objects. **************************************************************** From: Tucker Taft Sent: Thursday, June 9, 2011 7:40 PM Sorry I missed those Interface subpackages. Thanks for catching the omission. **************************************************************** From: Edmond Schonberg Sent: Thursday, June 9, 2011 7:44 PM No objection of course, These packages are used among other things to interface to foreign compilers, so they better be expandable. ****************************************************************