CVS difference for ai05s/ai05-0229-1.txt
--- ai05s/ai05-0229-1.txt 2011/04/01 01:53:10 1.12
+++ ai05s/ai05-0229-1.txt 2011/04/02 06:05:22 1.13
@@ -1,4 +1,4 @@
-!standard 13.2(5) 11-03-31 AI05-0229-1/07
+!standard 13.2(5) 11-04-01 AI05-0229-1/08
!standard 13.11.3(5)
!standard B.3.3(4)
!standard E.4.1(8)
@@ -295,13 +295,91 @@
into a user note.]
-** Unchanged - TBD ** -- Assigned to Ed.
+
===pragma Atomic, Atomic_Components, Independent,
Independent_Components, Volatile, Volatile_Components: (the pragmas are to be
obsolescent)
+
+
+Rewrite C.6(2-8)) as follows:
-C.6(14): No changes needed for Atomic, Atomic_Components, Independent,
-Independent_Components, Volatile, Volatile_Components.
+Static Semantics
+
+For an object declaration, a component declaration, or a full type declaration,
+the following representation aspects can be specified: Atomic, Volatile,
+and Independent.
+
+For an object declaration of an anonymous array object or
+a full type declaration of an array type, the following representation aspects
+can be specified: Atomic_Components, and Volatile_Components.
+
+For an object declaration of an anonymous array object or a full type declaration,
+the following representation aspect can be specified: Independent_Components.
+
+The type of these aspects is Boolean. If any of these aspects are directly
+specified, the aspect_definition shall be a static expression. If not specified
+(including by inheritance), each of these aspects are False.
+
+An atomic type is one for which the aspect Atomic is True. An atomic
+object (including a component) is one for which the aspect Atomic is True,
+or a component of an array for which the aspect Atomic_Components is True,
+or any object of an atomic type, other than objects obtained by evaluating
+a slice.
+
+A volatile type is one for which the aspect Volatile is True. A Volatile
+object (including a component) is one for which the aspect Volatile is
+True, or a component of an array for which the aspect Volatile_Components
+is True, or any object of a volatile type. In addition, every atomic type
+or object is also defined to be volatile. Finally, if an object is volatile,
+then so are all of its subcomponents.
+
+Delete C.6(9/3) [Now in Annex J.]
+
+Replace C.6(10) with the following two paragraphs:
+
+If one of these aspects is specified for a component_declaration, the declaration
+shall not be inherited. If aspect Independent_Components is specified for a
+full_type_declaration, the declaration shall be that of an array or record type.
+
+[These rules are needed to replace the resolution rules of C.6(9/3) for items
+not previously included. We want all components and types to have the "regular"
+aspects. - RLB]
+
+It is illegal to specify the aspect Atomic or Atomic_Components for an object
+or type if the implementation cannot support the indivisible reads and writes
+required by the aspect (see below).
+
+Replace C.6(13):
+
+If an aspect Volatile, Volative_components, Atomic or Atomic_Components is
+True for an stand-alone constant object, then the aspect Import shall
+also be specified for it.
+
+It is illegal to specify the aspect Independent or Independent_Components as
+True for a component, object or type if the implementation cannot provide the
+independent addressability required by the aspect (see 9.10).
+
+It is illegal to specify a representation aspect for a component, object or
+type for which the aspect Independent or Independent_Component is True,
+in a way that prevents the implementation from providing the
+independent addressability required by the aspect.
+
+
+Delete C.6(14) [Now in Annex J.]
+
+Replace C.6(14.1/3):
+
+When True, the aspects Independent and Independent_Components *specify as independently
+addressable* the named object or component(s), or in the case of a type,
+all objects of that type. All atomic objects are considered to be specified as
+independently addressable.
+
+[Editor's Note: We could simplify this section a tiny bit more by defining the
+xxx_Components aspects to only be defined for types, and saying that specifying
+the aspect on an anonymous array object sets the aspect of the (anonymous) type.
+This is the way Priority (for one example) is defined. Doing this would simplify
+the model (especially for implementations), but would have little impact on the
+wording, so I didn't change Ed's proposal. - Randy]
===pragma Asynchronous: (the pragma is to be obsolescent)
@@ -569,6 +647,8 @@
and only Preelaboration_Initialization (see 10.2.1) can be specified on a
formal_type_declaration.
+[Editor's Note: Pragma Preelaborable_Initialization is used in around 20
+language-defined packages; should these all be changed??]
===pragma Interrupt_Handler and Attach_Handler (the pragma is to be obsolescent)
@@ -940,28 +1020,239 @@
See AI05-0215-1.
-** Unchanged - TBD ** -- Assigned to Tucker.
===pragmas Convention, Export, Import: (the pragmas are to be obsolescent)
+
+Rewrite B.1 as follows: [Editor's note: Some parts of this are unchanged.]
+
+ B.1 Interfacing Aspects
+
+ An /interfacing/ aspect is a representation aspect that is one of the
+ aspects Import, Export, Link_Name, External_Name, or Convention.
+
+ Specifying aspect Import to have the value True is used to import
+ an entity defined in a foreign language into an Ada program, thus
+ allowing a foreign-language subprogram to be called from Ada, or a
+ foreign-language variable to be accessed from Ada. In contrast, specifying
+ aspect Export to have the value True is used to export an Ada entity to a
+ foreign language, thus allowing an Ada subprogram to be called from a
+ foreign language, or an Ada object to be accessed from a foreign
+ language. The Import and Export aspects are intended primarily for
+ objects and subprograms, although implementations are allowed to
+ support other entities. The Link_Name and External_Name aspects are
+ used to specify the link name and external name, respectively, to be
+ used to identify imported or exported entities in the external
+ environment.
+
+ The Convention aspect is used to indicate that an Ada entity should
+ use the conventions of another language. It is intended primarily for
+ types and “callback” subprograms. For example, “with Convention =>
+ Fortran” on the declaration of an array type Matrix implies that
+ Matrix should be represented according to the conventions of the
+ supported Fortran implementation, namely column-major order.
+
+ A pragma Linker_Options is used to specify the system linker
+ parameters needed when a given compilation unit is included in a
+ partition.
+
+ Syntax
+
+ The form of a pragma Linker_Options is as follows:
+
+ pragma Linker_Options(string_expression);
+
+ A pragma Linker_Options is allowed only at the place of a declarative_item.
+
+ Name Resolution Rules
+
+ The Import and Export aspects are of type Boolean.
+
+ The Link_Name and External_Name aspects are of type String.
+
+ The expected type for the string_expression in pragma Linker_Options, is
+ String.
+
+ Legality Rules
+
+ The aspect Convention shall be specified by a /convention_/identifier,
+ which shall be the name of a convention. The convention names are
+ implementation defined, except for certain language-defined ones, such
+ as Ada and Intrinsic, as explained in 6.3.1, “Conformance Rules”.
+ Additional convention names generally represent the calling
+ conventions of foreign languages, language implementations, or
+ specific run-time models. The convention of a callable entity is its
+ calling convention.
+
+ If L is a convention_identifier for a language, then a type T is said
+ to be compatible with convention L, (alternatively, is said to be an
+ L-compatible type) if any of the following conditions are met:
+
+ T is declared in a language interface package corresponding to L and
+ is defined to be L-compatible (see B.3, B.3.1, B.3.2, B.4, B.5),
+
+ Convention L has been specified for T, and T is eligible for
+ convention L; that is:
+
+ T is an array type with either an unconstrained or
+ statically-constrained first subtype, and its component type is
+ L-compatible,
+
+ T is a record type that has no discriminants and that only has
+ components with statically-constrained subtypes, and each component
+ type is L-compatible,
+
+ T is an access-to-object type, its designated type is L-compatible,
+ and its designated subtype is not an unconstrained array subtype,
+
+ T is an access-to-subprogram type, and its designated profile's
+ parameter and result types are all L-compatible.
+
+ T is derived from an L-compatible type,
+
+ The implementation permits T as an L-compatible type.
+
+ If a Convention aspect is specified for a type, then the type shall
+ either be compatible with or eligible for the specified convention.
+
+ Notwithstanding any rule to the contrary, a declaration with a True
+ Import aspect shall not have a completion.
+
+ An entity with a True Import aspect (or Export aspect) is said to be
+ imported (respectively, exported). An entity shall not be both imported
+ and exported.
+
+ The declaration of an imported object shall not include an explicit
+ initialization expression. Default initializations are not performed.
+
+ The type of an imported or exported object shall be compatible with
+ the specified Convention aspect, if any.
+
+ For an imported or exported subprogram, the result and parameter types
+ shall each be compatible with the specified Convention aspect, if any.
+
+ The Boolean_expression (if any) used to directly specify an Import or
+ export aspect shall be a static expression.
+ The string_expression used to directly specify an External_Name or
+ Link_Name aspect, and the string_expression of a pragma Linker_Options,
+ shall be static. An External_Name or Link_Name aspect shall be specified
+ only for an entity that is either imported or exported.
+
+ Static Semantics
+
+ The Convention aspect represents the calling convention or
+ representation convention of the entity. For an access-to-subprogram
+ type, it represents the calling convention of designated subprograms.
+ In addition:
+
+ A True Import aspect indicates that the entity is defined externally
+ (that is, outside the Ada program).
+ This aspect is never inherited; if not directly specified, the Import
+ aspect is False.
+
+ A True Export aspect indicates that the entity is used externally.
+ This aspect is never inherited; if not directly specified, the Import
+ aspect is False.
+
+ For an entity with a True Import or Export aspect, an external name,
+ link name, or both may also be specified.
+
+ An external name is a string value for the name used by a foreign
+ language program either for an entity that an Ada program imports, or
+ for referring to an entity that an Ada program exports.
+
+ A link name is a string value for the name of an exported or imported
+ entity, based on the conventions of the foreign language's compiler in
+ interfacing with the system's linker tool.
+
+ The meaning of link names is implementation defined. If neither a link
+ name nor the Address attribute of an imported or exported entity is
+ specified, then a link name is chosen in an implementation-defined
+ manner, based on the external name if one is specified.
+
+ Pragma Linker_Options has the effect of passing its string argument as
+ a parameter to the system linker (if one exists), if the immediately
+ enclosing compilation unit is included in the partition being linked.
+ The interpretation of the string argument, and the way in which the
+ string arguments from multiple Linker_Options pragmas are combined, is
+ implementation defined.
+
+ Dynamic Semantics
+
+ Notwithstanding what this International Standard says elsewhere, the
+ elaboration of a declaration with a True Import aspect
+ does not create the entity. Such an elaboration has no other
+ effect than to allow the defining name to denote the external entity.
+
+ Erroneous Execution
+
+ It is the programmer's responsibility to ensure that the use of
+ interfacing aspects does not violate Ada semantics; otherwise,
+ program execution is erroneous.
+
+ Implementation Advice
+
+ If an implementation supports Export to a given language, then
+ it should also allow the main subprogram to be written in that
+ language. It should support some mechanism for invoking the
+ elaboration of the Ada library units included in the system, and for
+ invoking the finalization of the environment task. On typical
+ systems, the recommended mechanism is to provide two subprograms
+ whose link names are "adainit" and "adafinal". Adainit should contain
+ the elaboration code for library units. Adafinal should contain the
+ finalization code. These subprograms should have no effect the second
+ and subsequent time they are called.
+
+ Automatic elaboration of preelaborated packages should be provided
+ when Export is specified.
+
+ For each supported convention L other than Intrinsic, an
+ implementation should support Import and Export specification for
+ objects of L-compatible types and for subprograms, and Convention
+ specification for L-eligible types and for subprograms, presuming the
+ other language has corresponding features. Specifying the Convention
+ aspect need not be supported for scalar types.
-Modify B.1(28) as follows:
+ NOTES
- Import, Export, and Convention pragmas are representation pragmas that
- specify the [c]{C}onvention aspect of representation{, using
- /convention_/identifiers that are identifiers specific to the
- Convention aspect}. In addition, Import and Export pragmas specify the
- [imported]{Import} and [exported]{Export (boolean)} aspects of
- representation, respectively{, along with the External_Name and
- Link_Name (string) aspects}. {These aspects may also be specified
- using an aspect_specification associated with the named entity, so
- long as the Import and Export aspect are not both specified as True
- for a single entity, and the External_Name or the Link_Name aspect are
- specified only if the Import or Export aspect is specified as True.
- [Redundant: In the absence of an interfacing pragma or an
- aspect_specification for the Convention aspect, the Convention aspect
- defaults to Ada for a user-declared entity, unless specified otherwise
- in this International Standard (see 6.3.1).]}
+ 1 Implementations may place restrictions on interfacing aspects; for
+ example, requiring each exported entity to be declared at the library
+ level.
+ 2 The Convention aspect in combination with the Import aspect
+ indicates the conventions for accessing external entities. It is
+ possible that the actual entity is written in assembly language, but
+ reflects the conventions of a particular language. For example, "with
+ Convention => Ada" can be used to interface to an assembly language
+ routine that obeys the Ada compiler's calling conventions.
+ 3 To obtain “call-back” to an Ada subprogram from a foreign language
+ environment, the Convention aspect should be specified both for the
+ access-to-subprogram type and the specific subprogram(s) to which
+ 'Access is applied.
+
+ 4 It is illegal to specify that both the Import and Export aspects of
+ an entity are true.
+
+ 6 See also 13.8, “Machine Code Insertions”.
+
+ 7 If both External_Name and Link_Name are specified for a given
+ entity, then the External_Name is ignored.
+
+ Examples
+
+ Example of interfacing aspects:
+
+ package Fortran_Library is
+ function Sqrt (X : Float) return Float
+ with Import => True, Convention => Fortran;
+
+ function Exp (X : Float) return Float
+ with Import => True, Convention => Fortran;
+ end Fortran_Library;
+
+[Editor's Note: Consider scrubbing AARM notes for "pragma Import", "pragma Export",
+and "pragma Convention". Should the dozen or so uses of pragma Convention (Intrinsic)
+in language-defined packages be changed??]
+
Add a new clause to Annex J:
[Note: The subclauses will be rearranged in alphabetical order - at the last
@@ -1309,7 +1600,7 @@
pragma Preelaborable_Initialization (direct_name);
Static Semantics
- A pragma Preelaborable_Initialization specifies the
+ A pragma Preelaborable_Initialization specifies that the
Preelaborable_Initialization aspect (see 10.2.1) of the
type denoted by its argument is True.
@@ -1333,6 +1624,100 @@
In addition to the places where Legality Rules normally apply (see 12.3),
these rules apply also in the private part of an instance of a generic unit.
+
+
+J.15.13 Shared variable pragmas
+
+Syntax
+
+The form for pragmas Atomic, Volatile, Independent, Atomic_Components, and
+Volatile_Components, and Independent_Components is as follows:
+
+ pragma Atomic(local_name);
+
+ pragma Volatile(local_name);
+
+ pragma Independent(component_local_name);
+
+ pragma Atomic_Components(array_local_name);
+
+ pragma Volatile_Components(array_local_name);
+
+ pragma Independent_Components(local_name);
+
+Name Resolution Rules
+
+The local_name in an Atomic or Volatile pragma shall resolve to denote either
+an object_declaration, a non-inherited component_declaration, or a
+full_type_declaration. The component_local_name in an Independent pragma shall
+resolve to denote a non-inherited component_declaration. The array_local_name
+in an Atomic_Components or Volatile_Components pragma shall resolve to denote
+the declaration of an array type or an array object of an anonymous type.
+The local_name in an Independent_Components pragma shall resolve to denote the
+declaration of an array or record type or an array object of an anonymous type.
+
+Static Semantics
+
+These pragmas are representation pragmas (see 13.1). Each of these pragmas
+specifies that the similarly named aspect (see C.6) of the type, object, or
+component denoted by its argument is True.
+
+Legality Rules
+
+The local_name of of each of these pragmas shall denote a declaration that may have
+the similarly named aspect specified.
+
+J.15.14 Interfacing pragmas
+
+An interfacing pragma is a representation pragma that is one of the pragmas Import,
+Export, or Convention. Their forms are as follows:
+
+ pragma Import(
+ [Convention =>] convention_identifier, [Entity =>] local_name
+ [, [External_Name =>] external_name_string_expression] [, [Link_Name =>] link_name_string_expression]);
+
+ pragma Export(
+ [Convention =>] convention_identifier, [Entity =>] local_name
+ [, [External_Name =>] external_name_string_expression] [, [Link_Name =>] link_name_string_expression]);
+
+ pragma Convention([Convention =>] convention_identifier,[Entity =>] local_name);
+
+For pragmas Import and Export, the argument for Link_Name shall not be given without
+the pragma_argument_identifier unless the argument for External_Name is given.
+
+Name Resolution Rules
+
+The expected type for a external_name_string_expression and a link_name_string_expression
+in an interfacing pragma is String.
+
+Legality Rules
+
+The convention_identifier of an interfacing pragma shall be the name of a convention (see B.1).
+
+A pragma Import shall be the completion of a declaration.
+
+The external_name_string_expression and link_name_string_expression of a pragma Import
+or Export shall be static.
+
+The local_name of of each of these pragmas shall denote a declaration that may have
+the similarly named aspect specified.
+
+Static Semantics
+
+An interfacing pragam specifies various aspects of the entity denoted by the
+local_name as follows:
+
+* The Convention aspect (see B.1) is convention_identifier.
+
+* A pragma Import specifies that the Import aspect (see B.1) is True.
+
+* A pragma Export specifies that the Export aspect (see B.1) is True.
+
+* For both pragma Import and Export, if an
+ external name is given in the pragma, the External_Name aspect
+ is specified to be external_name_string_expression. If a link name
+ is given in the pragma, the Link_Name aspect is specified to be the
+ link_name_string_expression.
*** Additional obsolescent pragmas here ***
Questions? Ask the ACAA Technical Agent