Version 1.9 of ai05s/ai05-0246-1.txt

Unformatted version of ai05s/ai05-0246-1.txt version 1.9
Other versions for file ai05s/ai05-0246-1.txt
!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)
Replace the paragraph:
A pragma Restrictions expresses the user's intent to abide by certain restrictions. This may facilitate the construction of simpler run-time environments.
by:
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)
Insert after the paragraph:
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.
the new paragraphs:
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 usage profile. The semantics of any profile_pragma_argument_associations are defined by the usage profile specified by the profile_identifier.
Static Semantics
A profile is equivalent to the set of configuration pragmas that is defined for each usage profile.
Post-Compilation Rules
A pragma Profile is a configuration pragma. There may be more than one pragma Profile for a partition.
!corrigendum 13.12.1(2/2)
Insert after the paragraph:
No_Implementation_Attributes
There are no implementation-defined attributes. This restriction applies only to the current compilation or environment, not the entire partition.
the new paragraphs:
No_Implementation_Identifiers
There are no usage names that denote declarations with implementation-defined identifiers that occur within language-defined packages. Such identifiers can arise as follows:
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.
!corrigendum 13.12.1(8/2)
Insert after the paragraph:
No compilation unit included in the partition shall depend semantically on the library unit identified by the name.
the new paragraphs:
Static Semantics
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.
!corrigendum D.13(1/2)
Replace the paragraph:
This clause specifies a mechanism for defining run-time profiles.
by:
This clause defines the Ravenscar profile.
!corrigendum D.13(2/2)
Delete the paragraph:
The form of a pragma Profile is as follows:
!corrigendum D.13(3/2)
Delete the paragraph:
pragma Profile (profile_identifier {, profile_pragma_argument_association});
!corrigendum D.13(4/2)
Replace the paragraph:
The profile_identifier shall be the name of a run-time profile. The semantics of any profile_pragma_argument_associations are defined by the run-time profile specified by the profile_identifier.
by:
The profile_identifier Ravenscar is a usage profile (see 13.12). For usage profile Ravenscar, there shall be no profile_pragma_argument_associations.
!corrigendum D.13(5/2)
Replace the paragraph:
A profile is equivalent to the set of configuration pragmas that is defined for each run-time profile.
by:
The usage profile Ravenscar is equivalent to the following set of pragmas:
pragma Task_Dispatching_Policy (FIFO_Within_Priorities); pragma Locking_Policy (Ceiling_Locking); pragma Detect_Blocking; pragma 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);
Implementation Requirements
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.
Implementation Advice
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)
Replace the paragraph:
A pragma Profile is a configuration pragma. There may be more than one pragma Profile for a partition.
by:
NOTES
37 The effect of the Max_Entry_Queue_Length => 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.

****************************************************************
Questions? Ask the ACAA Technical Agent