Version 1.2 of 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
!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(11):
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(3/2):
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).
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:
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_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:
!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_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.
!example
pragma Profile(No_Implementation_Extensions);
--!corrigendum 13.12.1(3/2)
!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.
****************************************************************
Questions? Ask the ACAA Technical Agent