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

Unformatted version of ai05s/ai05-0246-1.txt version 1.2
Other versions for file ai05s/ai05-0246-1.txt

!standard 13.12(1)          11-03-16 AI05-0246-1/01
!standard 13.12(11)
!standard 13.12.1(3/2)
!standard 13.12.1(8/2)
!standard D.13.1(1/2)
!class Amendment 11-03-16
!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
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_*.
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.
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.
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(11):
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(3/2):
* 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).
Note that Standard.Long_Integer and Standard.Long_Float are considered language-defined identifiers, but identifiers such as Standard.Short_Short_Integer are considered implementation-defined.
Add after 13.2.1(8/2):
The following /profile_/identifier is language-defined:
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_Attributes, No_Implementation_Pragmas, No_Implementation_Identifiers, No_Implementation_Aspects, 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:
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_Aspects 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.
pragma Profile(No_Implementation_Extensions);
--!corrigendum 13.12.1(3/2)
!ACATS test
Add a ACATS B test for this feature.
No ASIS effect (Restrictions and Profiles are not handled specially by ASIS).

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.


Questions? Ask the ACAA Technical Agent