!standard 3.2.4(0) 12-02-03 AI05-0269-1/06 !standard 3.5(56/2) !standard 3.10.1(13) !standard 4.1.5(0) !standard 4.1.6(0) !standard 4.5.2(27) !standard 4.5.2(28) !standard 4.5.2(30.2/2) !standard 4.9(33) !standard 6.1.1(0) !standard 7.3(15) !standard 7.3.2(0) !standard 7.4(2) !standard 7.6(17/2) !standard 7.6.1(13/2) !standard 13.3(65) !standard 13.11(21) !standard 13.11.3(5) !standard 13.11.4(0) !standard 13.13.2(26) !standard A.16.1(0) !standard A.17(19/2) !standard A.18.2(147/2) !standard A.18.2(230/2) !standard A.18.3(86/2) !standard A.18.3(144/2) !standard A.18.4(41/2) !standard A.18.5(61/2) !standard A.18.6(94/2) !standard A.18.7(36/2) !standard A.18.7(96/2) !standard A.18.8(85/2) !standard A.18.9(113/2) !standard A.18.10(0) !standard A.18.18(0) !standard A.18.21(0) !standard A.18.22(0) !standard A.18.23(0) !standard A.18.24(0) !standard B.1(1) !standard B.1(51) !standard B.3.3(1/2) !standard D.2.4(11/2) !standard D.10(10) !standard D.14(11/2) !standard D.16.1(0) !class Amendment 11-11-09 !status Amendment 2012 12-01-12 !status work item 11-11-09 !status received 11-07-20 !priority Low !difficulty Easy !qualifier Error !subject Editorial comments on Draft 14 !summary Handle editorial comments on Draft 14 of the Ada 2012 Standard. !proposal (1) Drop Pragma Preelaborate from D.16.1(3/3) (the package depends on Ada.Real_Time, which is not preelaborated. (2) The Implementation Advice for bounded maps and sets ought to include the kind, so the M.3 summary does not look repetitive. (3) We should always use "holder" as an adjective; using "holder container" if no other option exists. There is only one element in a holder, so use "the element" instead of "elements". (4) There is no type named "Root_Subpool_Type", this should be fixed. (5) 13.11.3(5/3) does not tell us where the aspect is allowed. (6) The list of packages for 13.12.1(2.1/3) includes Interfaces.C.Pointers, which is a generic package. But the wording does not strictly apply to it (a generic package is not a package, and a instance of it is not a language-defined package). This should be fixed. (7) "The aspect Storage_Size" in 13.3(65.2/3) is inconsistent with the following rules which use "The Storage_Size aspect". (8) The term "invididual membership test" is used twice before it is defined, which is confusing and unnecessary. Add a separate definition for the term before it is used. (9) It's not clear whether the first "designated type" talked about in 4.5.2(30.3/3) is that of the tested type or of the simple_expression. Clarify that. (10) 4.9(32.5/3) talks about how the selecting_expression "is static and is not covered by" a discrete_choice_list. This doesn't make much sense, because a discrete_choice is defined to cover a value by 3.8.1(9) (not an expression). "Value" (of the selecting_expression) needs to be mentioned somehow. (11) The introduction of 3.2.4 is the first place that aspects and aspect_specifications are mentioned in the Standard. We need a strong forward reference. (12) 3.2.4(7/3) says "a static expression that does not raise any exception;", but an expression that could raise an exception is not static by 4.9(34/3), so the part about the exception is just noise. (13) We shall not use "shall" in notes, so 3.10.1(13.1/3) should be fixed. (14) There are too many expecteds in 4.1.5(5/3). Get rid of one of them. (15) "All of such" should be "all such" in 4.1.6(3/3). (16) 3.5(56.1/3) is confusing. Please clarify. (17) The first sentence of A.16.1(16/3) ends abruptly. Please improve. (18) In A.17(19/3), the second ""variable" should be plural. (19) In Annex B, we usually say "the aspect". The first two uses in B.1(1/3) say "aspect " instead. Please change. (20) It would be nice for a type to be given in the example of B.1(51/3). (21) In B.3.3(1/3), "leaves no space" is really informal; "allocates no space" would be better. (22) 13.13.2(26) says that the discriminants are written with "S'Write"; but S in this context is the discriminanted record type. This should be fixed. (23) 13.11(21.5/3) says that "The Alignment parameter is at least D'Alignment ...". This allows passing 5 if D'Alignment is 4, and is generally weird. (24) The introductory text for A.18.2(147.13/3) and many others is clunky. (25) "the" loop parameter should be "a" loop parameter in A.18.2(230.2/3) and many other functions. We also should add cross-references to where these things are defined. (26) The definition of "decendant" and "ancestor" in A.18.10 is inconsistent (and inconsistent with the use of these terms elsewhere in the Standard). Some other text is unclear. (27) The definition of Separate_Interrupt_Clocks_Supported should have a forward reference to D.14.3 where it is used. (28) D.10(10) raises Program_Error if a second is suspended on a suspension object; D.10(10.1/3) does not have this rule. That appears to be an omission. (29) D.2.4(11/3) would allow priority inversion if Yield_To_Higher was called during a protected action. In addition, it isn't clear that this permission only applies to partitions using the Non_Premptive_FIFO_Withing_Priorities policy. (30) In 6.1.1(32/3) [Draft 14], "primitive" is used as a noun; this should be "primitive subprogram". (31) 7.3(15) is not really a definition, but the italics imply that it is. Now that we've decided that this definition is in 3.4 (see AI-0110-1), this wording should reflect that. (32) 7.3.2(22/3) shows that it is intended for invariant checks to apply to all visible subprograms, including inherited ones. But 7.3.2(15/3) says "explicitly declared", which excludes inherited subprograms from the checks of 7.3.2(14-18/3). This should be fixed. (33) 7.4(2/3) is awkward, as the "unless" seems to bind with "shall". (34) 7.6(17.1/3) has the definition on the second use of the term. Move it to the first use. (35) 7.6.1(13/3) talks about an anonymous object being "part of the actual parameter expression". But of course it can't be part of the expression, it's part of the result of evaluating the expression. !wording (1) Remove pragma Preelaborate from D.16.1(3/3). (2) Add "hashed" to A.18.21(21/3), "ordered" to A.18.22(18/3), "hashed" to A.18.23(20/3), and "ordered to A.18.24(17/3), in front of "map" or "set". (3) Change "holder" to "holder container" in A.18.18(70,72,74/3). Change "elements" to "the element" in A.18.18(73/3). (4) Replace "Root_Subpool_Type" with "Root_Subpool" in 13.11.4(19/3). (5) Modify 13.11.3(5/3): The language-defined aspect Default_Storage_Pool may be {specified for a generic instance; it defines} [used to define] the default pool for access types within an instance. (6) Modify 13.12.1(2.1/3): There are no usage names that denote declarations with implementation-defined identifiers that occur within language-defined packages {or instances of language-defined generic packages}. (7) Modify 13.3(65.2/3): Storage_Size The [aspect] Storage_Size {aspect} ... (8) Add before 4.5.2(27/3): An *individual membership test* is the membership test of a single membership_choice. Remove the italics from 4.5.2(28/3). (9) Modify 4.5.2(30.3/3): "...if the designated type {of the tested type} is tagged ..." (10) Modify 4.9(32.5/3): "...whose /selecting_/expression is static and {whose value} is not covered by the corresponding discrete_choice_list..." (11) Add to the end of 3.2.4(1/3): General rules for aspects and aspect_specifications are found in chapter 13 (13.1 and 13.3.1 respectively). (12) Modify 3.2.4(7/3): "a static expression[ that does not raise any exception];" (13) Modify 3.10.1(13.1/3): "...statement {cannot}[shall not] be of an...". (14) Replace 4.1.5(5/3) by: "The expected type for the reference_object_name in a generalized_reference is any reference type." (15) Modify 4.1.6(3/3): "... All [of] such functions ..." (16) Replace 3.5(56.1/3) with: An implementation may extend the Wide_Wide_Value, Wide_Value, and Value attributes of a character type to accept strings of the form "Hex_hhhhhhhh" (ignoring case) for any character (not just the ones for which Wide_Wide_Image would produce that form -- see 3.5.2), as well as three-character strings of the form "'X'", where X is any character, including non-graphic characters. (17) Modify A.16.1(16/3): In addition to the operations provided in package Directories.Hierarchical_File_Names, {the} operations in package Directories can be used {with hierarchical file names}. In particular, functions Full_Name, Base_Name, and Extension are {provide additional capabilities for}[usable with] hierarchical file names. (18) Modify A.17(19/3): "...all existing environment variable{s}..." (19) Change "Specifying aspect Import to..." to "Specifying the Import aspect to..." and similarly for Export in B.1(1/3). (20) Replace the example B.1(51/3) with: package Fortran_Library is function Sqrt (X : Float) return Float with Import => True, Convention => Fortran; type Matrix is array (Natural range <>, Natural range <>) of Float with Convention => Fortran; function Invert (X : Matrix) return Matrix with Import => True, Convention => Fortran; end Fortran_Library; (21) Modify B.3.3(1/3): "...[leaves]{allocates} no space...". (22) Modify 13.13.2(26): "... S'Output first writes the discriminants (using [S'Write]{the Write attribute of the discriminant type} for each), and S'Input first reads the discriminants (using [S'Read]{the Read attribute of the discriminant type} for each)." (23) Modify 13.11(21.5/3): "... The Alignment parameter is {a nonzero integral multiple of}[at least] @i'Alignment if @i is a specific type, and otherwise is {a nonzero integral multiple}[at least] of the alignment of the specific type identified by the tag of the object being created. ..." (24) Modify A.18.2(147.13/3), A.18.2(147.16/3), A.18.3(86.6/3), A.18.3(86.9/3), A.18.4(41.6/3), A.18.4(41.9/3), A.18.7(36.5/3), A.18.7(96.10/3), A.18.10(125/3), A.18.10(126/3): "This function (combined with the and Implicit_Dereference aspects) provides a convenient way to gain access to {an}[the] individual element[s] of a {vector|list|map|set|tree}[container] {given}[starting with] ." [Note: The text is to be the same as in the original paragraph; it is one of the enclosed options.] (25) Modify A.18.2(230.2/3), A.18.2(230.4/3), A.18.3(144.2/3), A.18.3(144.4/3), A.18.5(61.2/3), A.18.6(94.2/3), A.18.8(85.2/3), A.18.9(113.2/3), A.18.10(155/3), A.18.10(157/3), A.18.10(217/3): "...Iterate returns a iterator object {(see 5.5.1)} that will generate a value for [the] {a} loop parameter {(see 5.5.2)} designating each node in Container, ..." (26) Modify A.18.10(3/3): ... The root node provides a place to add nodes to an otherwise empty tree and represents the [bottom] {base} of the tree. Modify A.18.10(4/3): A node that has no children is called a leaf node. The ancestors of a node are the {node itself, its} parent node, the parent of the parent node, and so on until a node with no parent is reached. Similarly, the descendants of a node are the {node itself, its} child nodes, the children of each child node, and so on. Modify A.18.10(5/3): The nodes of a subtree can be visited in several different orders. For a depth-first order, [the last step of] {after} visiting a node{,} [is to visit] the nodes of its child list {are each visited in depth-first order, with each child visited in natural order (first child to last child)}[order, recursively]. Modify A.18.10(140/3): the subtree designated by Position (that is, {all descendants of} the node designated by Position [and all of the descendant nodes of that node] {including the node itself}) Modify A.18.10(174/3): ... Otherwise, Delete_Children removes (from Container) all of the [child nodes of Parent along with their descendant nodes] {descendants of Parent other than Parent itself}. Modify A.18.10(178/3) and A.18.10(181/3): ... if Position designates an ancestor of Parent [or is equal to Parent] {(including Parent itself)} ... Modify AARM notes A.18.10(178.a/3, 181.a/3, 187.a/3): Reason: We can't allow moving the subtree of Position to a {proper} descendant node of the subtree, as the descendant node will be part of the subtree being moved. ... Modify A.18.10(186/3): * if Source_Parent is an ancestor of Target_Parent {other than Target_Parent itself}, then Constraint_Error is propagated; else Modify A.18.10(187/3, 188/3, 190/3): ... the child elements (and [their] {the further} descendants) of Source_Parent ... Modify A.18.10(190/3): ... If Source_Parent is an ancestor of Target_Parent {other than Target_Parent itself}, then ... (27) Add "(see D.14.3)" to the end of D.14(11/3). (28) Add "Program_Error is raised upon calling Suspend_Until_True_And_Set_Deadline if another task is already waiting on that suspension object." as the penultimate sentence of D.10(10.1/3). (29) Modify D.2.4(11/3): "...may allow a task {of a partition using the Non_Premptive_FIFO_Within_Priorities policy} to execute..." "...does not contain {any calls to Yield_to_Higher, } any subprograms..." (30) Modify 6.1.1(32/3): "...primitive {subprogram}..." (three places). (31) In 7.3(15), replace the italisized "characteristics" with "characteristics (see 3.4)", as the definition of these things live there, not here. (32) In 7.3.2(15/3), delete "explicitly" (these checks need to apply to inherited routines as well as explictly declared ones). (33) In 7.4(2/3), replace the last sentence with: "Unless the Import aspect (see B.1) is True for a deferred constant declaration, the deferred constant declaration requires a completion, which shall be a full constant declaration (called the *full declaration* of the deferred constant)." (34) Replace the latter part of 7.6(17.1/3) with: For such an assignment, the anonymous object might be *built in place*, in which case the assignment does not involve any copying. Under certain circumstances, the anonymous object is required to be built in place. In particular: (35) Modify 7.6.1(13/3): "...If such an anonymous object is part of {the result of evaluating} the actual parameter expression for..." !discussion For (23), we copy the wording of 13.3(26.3/2). For (34), the commenter would have preferred wording closer to the Ada 2005 wording, something along the lines of: "For such an assignment, the result may be *built in place*, that is, directly in the target object and not by means of an anonymous object." Unfortunately, that's wrong with the model used by the Standard. The anonymous object always exists (even when built-in-place), it just is colocated with the target object and thus no copying is needed to assign it (this is called *mutation*). We had to adopt this (admittedly bizarre) model to deal with corner cases where it is possible to tell the differences between the target object and the anonymous object, which may have different types, tags, and finalization. !corrigendum 3.2.4(0) @dinsc [A placeholder to cause a conflict; the real wording is found in the conflict file.] !corrigendum 3.5(56/2) @dinsa An implementation may extend the Wide_Wide_Value, Wide_Value, Value, Wide_Wide_Image, Wide_Image, and Image attributes of a floating point type to support special values such as infinities and NaNs. @dinss An implementation may extend the Wide_Wide_Value, Wide_Value, and Value attributes of a character type to accept strings of the form "Hex_hhhhhhhh" (ignoring case) for any character (not just the ones for which Wide_Wide_Image would produce that form @emdash see 3.5.2), as well as three-character strings of the form "'@i'", where @i is any character, including non-graphic characters. !corrigendum 3.10.1(13) @dinsa @xindent<@s9<85 Within a @fa, an @fa and a corresponding @fa cannot be separated by an intervening body. This is because a type has to be completely defined before it is frozen, and a body freezes all types declared prior to it in the same @fa (see 13.14).>> @dinst @xindent<@s9<86 A @fa that denotes an object of an incomplete view is defined to be of a limited type. Hence, the target of an assignment statement cannot be of an incomplete view.>> !corrigendum 4.1.5(0) @dinsc [A placeholder to cause a conflict; the real wording is found in the conflict file.] !corrigendum 4.1.6(0) @dinsc [A placeholder to cause a conflict; the real wording is found in the conflict file.] !corrigendum 4.5.2(27) @dinsb For the evaluation of a membership test using @b whose @fa has a single @fa, the @fa and the @fa are evaluated in an arbitrary order; the result is the result of the individual membership test for the @fa. @dinst An @i is the membership test of a single @fa. !corrigendum 4.5.2(28) @drepl An @i yields the result True if: @dby An individual membership test yields the result True if: !corrigendum 4.5.2(30.2/2) @drepl @xbullet is not null.> @dby @xbullet is not null;> @xbullet is convertible to the tested type and its accessibility level is no deeper than that of the tested type; further, if the designated type of the tested type is tagged and the @fa is non-null, the tag of the object designated by the value of the @fa is covered by the designated type of the tested type.> !corrigendum 4.9(33) @drepl A static expression is evaluated at compile time except when it is part of the right operand of a static short-circuit control form whose value is determined by its left operand. This evaluation is performed exactly, without performing Overflow_Checks. For a static expression that is evaluated: @dby @xbullet@fa of a @fa whose @i@fa is static and whose value is not covered by the corresponding @fa; or> A static expression is evaluated at compile time except when it is statically unevaluated. The compile-time evaluation of a static expression is performed exactly, without performing Overflow_Checks. For a static expression that is evaluated: !corrigendum 6.1.1(0) @dinsc [A placeholder to cause a conflict; the real wording is found in the conflict file.] !corrigendum 7.3(15) @drepl A declaration of a partial view and the corresponding @fa define two views of a single type. The declaration of a partial view together with the visible part define the operations that are available to outside program units; the declaration of the full view together with the private part define other operations whose direct use is possible only within the declarative region of the package itself. Moreover, within the scope of the declaration of the full view, the @i of the type are determined by the full view; in particular, within its scope, the full view determines the classes that include the type, which components, entries, and protected subprograms are visible, what attributes and other predefined operations are allowed, and whether the first subtype is static. See 7.3.1. @dby A declaration of a partial view and the corresponding @fa define two views of a single type. The declaration of a partial view together with the visible part define the operations that are available to outside program units; the declaration of the full view together with the private part define other operations whose direct use is possible only within the declarative region of the package itself. Moreover, within the scope of the declaration of the full view, the characteristics (see 3.4) of the type are determined by the full view; in particular, within its scope, the full view determines the classes that include the type, which components, entries, and protected subprograms are visible, what attributes and other predefined operations are allowed, and whether the first subtype is static. See 7.3.1. !corrigendum 7.3.2(0) @dinsc [A placeholder to cause a conflict; the real wording is found in the conflict file.] !corrigendum 7.4(2) @drepl A @i is an @fa with the reserved word @b but no initialization expression. The constant declared by a deferred constant declaration is called a @i. A deferred constant declaration requires a completion, which shall be a full constant declaration (called the @i of the deferred constant), or a @fa Import (see Annex B). @dby A @i is an @fa with the reserved word @b but no initialization expression. The constant declared by a deferred constant declaration is called a @i. Unless the Import aspect (see B.1) is True for a deferred constant declaration, the deferred constant declaration requires a completion, which shall be a full constant declaration (called the @i of the deferred constant). !corrigendum 7.6(17/2) @dinsa [A placeholder to cause a conflict; the real wording is found in the conflict file.] @dinst The real text is not here. !corrigendum 7.6.1(13/2) !AI-0066-1 !AI-0142-4 !AI-0269-1 @drepl The master of an object is the master enclosing its creation whose accessibility level (see 3.10.2) is equal to that of the object. @dby The master of an object is the master enclosing its creation whose accessibility level (see 3.10.2) is equal to that of the object, except in the case of an anonymous object representing the result of an @fa or function call. If such an anonymous object is part of the result of evaluating the actual parameter expression for an explicitly aliased parameter of a function call, the master of the object is the innermost master enclosing the evaluation of the @fa or function call, excluding the @fa or function call itself. Otherwise, the master of such an anonymous object is the innermost master enclosing the evaluation of the @fa or function call, which may be the @fa or function call itself. !corrigendum 13.3(65) @ddel [A placeholder to cause a conflict; the real wording is found in the conflict file.] !corrigendum 13.11(21) @Comment{This is a partial change, the entire change is found in the conflict file.} @dinsa If Storage_Pool is specified for an access type, then if Allocate can satisfy the request, it should allocate a contiguous block of memory, and return the address of the first storage element in Storage_Address. The block should contain Size_In_Storage_Elements storage elements, and should be aligned according to Alignment. The allocated storage should not be used for any other purpose while the pool element remains in existence. If the request cannot be satisfied, then Allocate should propagate an exception (such as Storage_Error). If Allocate behaves in any other manner, then the program execution is erroneous. @dinss @s8<@i> For each of the calls of Allocate described above, @i

(equivalent to @i'Storage_Pool) is passed as the Pool parameter. The Size_In_Storage_Elements parameter indicates the number of storage elements to be allocated, and is no more than @i'Max_Size_In_Storage_Elements, where @i is the designated subtype of @i. The Alignment parameter is a nonzero integral multiple of @i'Alignment if @i is a specific type, and otherwise is a nonzero integral multiple of the alignment of the specific type identified by the tag of the object being created. The Alignment parameter is no more than @i'Max_Alignment_For_Allocation. The result returned in the Storage_Address parameter is used as the address of the allocated storage, which is a contiguous block of memory of Size_In_Storage_Elements storage elements. Any exception propagated by Allocate is propagated by the construct that contained the call. !corrigendum 13.11.4(0) @dinsc [A placeholder to cause a conflict; the real wording is found in the conflict file.] !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 or instances of language-defined generic packages. Such identifiers can arise as follows:> !corrigendum 13.13.2(26) @drepl @xbullet is an array type, S'Output first writes the bounds, and S'Input first reads the bounds. If @i has discriminants without defaults, S'Output first writes the discriminants (using S'Write for each), and S'Input first reads the discriminants (using S'Read for each).> @dby @xbullet is an array type, S'Output first writes the bounds, and S'Input first reads the bounds. If @i has discriminants without defaults, S'Output first writes the discriminants (using the Write attribute of the discriminant type for each), and S'Input first reads the discriminants (using the Read attribute of the discriminant type for each).> !corrigendum A.16.1(0) @dinsc [A placeholder to cause a conflict; the real wording is found in the conflict file.] !corrigendum A.17(19/2) @drepl If the external execution environment supports environment variables, then Clear deletes all existing environment variable with the given name. Otherwise Program_Error is propagated. @dby If the external execution environment supports environment variables, then Clear deletes all existing environment variables with the given name. Otherwise, Program_Error is propagated. !corrigendum A.18.2(147/2) @dinsa Force a conflict; the real text is found in the conflict file. @dinst Nothing. !corrigendum A.18.2(230/2) @dinsa Force a conflict; the real text is found in the conflict file. @dinst Nothing. !corrigendum A.18.3(86/2) @dinsa Force a conflict; the real text is found in the conflict file. @dinst Nothing. !corrigendum A.18.3(144/2) @dinsa Force a conflict; the real text is found in the conflict file. @dinst Nothing. !corrigendum A.18.4(41/2) @dinsa Force a conflict; the real text is found in the conflict file. @dinst Nothing. !corrigendum A.18.5(61/2) @drepl Force a conflict; the real text is found in the conflict file. @dby Nothing. !corrigendum A.18.6(94/2) @drepl Force a conflict; the real text is found in the conflict file. @dby Nothing. !corrigendum A.18.7(36/2) @dinsa Force a conflict; the real text is found in the conflict file. @dinst Nothing. !corrigendum A.18.7(96/2) @dinsa Force a conflict; the real text is found in the conflict file. @dinst Nothing. !corrigendum A.18.8(85/2) @drepl Force a conflict; the real text is found in the conflict file. @dby Nothing. !corrigendum A.18.9(113/2) @drepl Force a conflict; the real text is found in the conflict file. @dby Nothing. !corrigendum A.18.10(0) @dinsc [A placeholder to cause a conflict; the real wording is found in the conflict file.] !corrigendum A.18.18(0) @dinsc [A placeholder to cause a conflict; the real wording is found in the conflict file.] !corrigendum A.18.21(0) @dinsc [A placeholder to cause a conflict; the real wording is found in the conflict file.] !corrigendum A.18.22(0) @dinsc [A placeholder to cause a conflict; the real wording is found in the conflict file.] !corrigendum A.18.23(0) @dinsc [A placeholder to cause a conflict; the real wording is found in the conflict file.] !corrigendum A.18.24(0) @dinsc [A placeholder to cause a conflict; the real wording is found in the conflict file.] !corrigendum B.1(1) @drepl A @fa Import 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, a @fa Export 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 @fas Import and Export are intended primarily for objects and subprograms, although implementations are allowed to support other entities. @dby An @i aspect is a representation aspect that is one of the aspects Import, Export, Link_Name, External_Name, or Convention. Specifying the Import aspect 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 the Export aspect 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. !corrigendum B.1(51) @drepl @xcode<@b Fortran_Library @b @b Sqrt (X : Float) @b Float; @b Exp (X : Float) @b Float; @b @b Import(Fortran, Sqrt); @b Import(Fortran, Exp); @b Fortran_Library;> @dby @xcode<@b Fortran_Library @b @b Sqrt (X : Float) @b Float @b Import =@> True, Convention =@> Fortran; @b Matrix @b (Natural @b <@>, Natural @b <@>) @b Float @b Convention =@> Fortran; @b Invert (M : Matrix) @b Matrix @b Import =@> True, Convention =@> Fortran; @b Fortran_Library;> !corrigendum B.3.3(1/2) @drepl A pragma Unchecked_Union specifies an interface correspondence between a given discriminated type and some C union. The pragma specifies that the associated type shall be given a representation that leaves no space for its discriminant(s). @dby Specifying aspect Unchecked_Union to have the value True defines an interface correspondence between a given discriminated type and some C union. The aspect requires that the associated type shall be given a representation that allocates no space for its discriminant(s). !corrigendum D.2.4(11/2) @drepl Since implementations are allowed to round all ceiling priorities in subrange System.Priority to System.Priority'Last (see D.3), an implementation may allow a task to execute within a protected object without raising its active priority provided the associated protected unit does not contain pragma Interrupt_Priority, Interrupt_Handler, or Attach_Handler. @dby Since implementations are allowed to round all ceiling priorities in subrange System.Priority to System.Priority'Last (see D.3), an implementation may allow a task of a partition using the Non_Premptive_FIFO_Within_Priorities policy to execute within a protected object without raising its active priority provided the associated protected unit does not contain any calls to Yield_To_Higher, any subprograms with Interrupt_Handler or Attach_Handler specified, nor does the unit have aspect Interrupt_Priority specified. !corrigendum D.10(10) @dinsa Program_Error is raised upon calling Suspend_Until_True if another task is already waiting on that suspension object. Suspend_Until_True is a potentially blocking operation (see 9.5.1). @dinst The procedure Suspend_Until_True_And_Set_Deadline blocks the calling task until the state of the object S is True; at that point the task becomes ready with a deadline of Ada.Real_Time.Clock + TS, and the state of the object becomes False. Program_Error is raised upon calling Suspend_Until_True_And_Set_Deadline if another task is already waiting on that suspension object. Suspend_Until_True_And_Set_Deadline is a potentially blocking operation. !corrigendum D.14(11/2) @drepl The @i or CPU time of a given task is defined as the time spent by the system executing that task, including the time spent executing run-time or system services on its behalf. The mechanism used to measure execution time is implementation defined. It is implementation defined which task, if any, is charged the execution time that is consumed by interrupt handlers and run-time services on behalf of the system. @dby The @i or CPU time of a given task is defined as the time spent by the system executing that task, including the time spent executing run-time or system services on its behalf. The mechanism used to measure execution time is implementation defined. The Boolean constant Interrupt_Clocks_Supported is set to True if the implementation separately accounts for the execution time of interrupt handlers. If it is set to False it is implementation defined which task, if any, is charged the execution time that is consumed by interrupt handlers. The Boolean constant Separate_Interrupt_Clocks_Supported is set to True if the implementation separately accounts for the execution time of individual interrupt handlers (see D.14.3). !corrigendum D.16.1(0) @dinsc [A placeholder to cause a conflict; the real wording is found in the conflict file.] !ACATS Test None needed. !ASIS No change needed. !appendix From: Steve Baird Sent: Friday, March 11, 2011 7:06 PM [This message was misplaced which is why it is getting handled in this AI; only the relevant part is included here.] While looking at this, I did notice a minor wording issue. In 13.13.2(26), the parenthesized wording eems wrong: If T has discriminants without defaults, S'Output first writes the discriminants (using S'Write for each), and S'Input first reads the discriminants (using S'Read for each). S is a discriminated subtype. We are using S'Write and S'Read to write/read single discriminant values? Probably "using S'Write" should be replaced with something like "using the Write attribute of each dicriminant type", and similarly for Read. **************************************************************** From: Bob Duff Sent: Wednesday, September 15, 2010 4:39 PM [This thread was unintentionally ignored and just now has been rediscovered, which is why it is getting handled in this AI - Editor.] AI05-0193-1: Alignment of allocators says: The Alignment parameter is at least D'Alignment if D is a specific type, and otherwise is at least the alignment of the specific type identified by the tag of the object being created. The Alignment parameter is no more than D'Max_Alignment_For_Allocation. Shouldn't it say it's "equal to or stricter than D'Alignment"? That is, equal to D'Alignment, or some positive integer multiple thereof. Because if D'Alignment is 4, you don't want to pass Alignment => 5 to Allocate. 4, 8, or 16 should be OK. 12 is weird, but still OK, I guess. **************************************************************** From: Robert Dewar Sent: Wednesday, September 15, 2010 4:41 PM Only powers of 2 make sense for alignments anyway, so in practice greater/less than mean the same as multiple/factor **************************************************************** From: Tucker Taft Sent: Wednesday, September 15, 2010 5:05 PM I agree "stricter" is more correct. Do we use that term elsewhere? **************************************************************** From: Bob Duff Sent: Wednesday, September 15, 2010 5:39 PM > I agree "stricter" is more correct. > Do we use that term elsewhere? Only in the AARM, as far as I know. I don't think we need to have a formal definition of "stricter" in order to use it in the RM. It's clear what it means. Or we can just leave it alone, and trust implementers to never pass Alignment=>5 or the like. Re: Robert's comment: I would have been happy with a rule saying Alignment must be a power of 2. I can't imagine any hardware (past, present, or future) where anything else would make sense. I'd be interested in hearing of counter-examples, if such exist[ed]! **************************************************************** From: Robert Dewar Sent: Wednesday, September 15, 2010 6:11 PM Certainly GNAT requires alignments to be a power of 2 **************************************************************** From: Tucker Taft Sent: Wednesday, September 15, 2010 6:09 PM > I don't think we need to have a formal definition of "stricter" in > order to use it in the RM. > It's clear what it means. ... What I was really asking was how do we require that one alignment be stricter than another alignment in other places in the manual. I just looked in the section on the 'Alignment attribute, and we always talk in terms of one alignment being a multiple of another alignment. So I think we should use that terminology here, rather than "greater" or "stricter". **************************************************************** From: Bob Duff Sent: Wednesday, September 15, 2010 6:31 PM OK, that makes sense. [Randy will no doubt include this in the appendix of the AI in a way that makes the referent of "that" in "that makes sense" unclear. Sigh.] [Editor's note: I did my best to follow his instructions. :-) If you the reader are really confused, the preceeding message is the referent.] **************************************************************** From: Randy Brukardt Sent: Monday, September 27, 2010 5:59 PM Forget my filing system: my new phone just showed "OK, that makes sense" with all of the quoted stuff eliminated. So I didn't find out what you meant until I looked at it here in the office. Probably best to write a few more words (but that's not fun when answering from a phone). **************************************************************** From: Bob Duff Sent: Monday, September 27, 2010 6:19 PM Reading e-mail on a phone is something I would never consider doing. I realize that makes me a luddite. ;-) But seriously, I don't think you should be vigorously trying to keep the !appendix sections small. Over-quoting is a sin, but underquoting is a worse sin. I really find it hard to follow the conversation when I can't tell what someone is replying to. And I was deliberately yanking your chain when I wrote just "OK, that makes sense.", which is incomprehensible without context. ;-) **************************************************************** From: Randy Brukardt Sent: Friday, January 27, 2012 1:53 AM A couple of weeks ago, I responded to one of Steve's comments thusly: > > 13.11(21.5/3) says > > The Alignment parameter is at least D'Alignment if D is a > > specific type, ... > > > > It does seem odd that if D'Alignment is 4, then this would allow > > passing in a value of 5. > > > > We may have already talked about this one and decided to ignore it. > > I vaguely remember such a discussion, but it doesn't seem to appear in > the filed e-mail (or we decided to ignore it). > > It doesn't seem too critical; it sounds hard to nail this down > perfectly. (I can't think of a reason to support an alignment of, say > 6, but I wouldn't be surprised of someone had a reason on some unusual > machine. So requiring only powers-of-two along wouldn't seem > appropriate to me.) I just ran across the old e-mail discussion (from September 2010!). Tucker suggested using "multiple" as that is what 13.3 uses when comparing to alignments. (Actually, the wording is "nonzero integral multiple".) It seems that your editor was supposed to make this change, but it got lost in a blizzard of mail on other topics. So the wording should be: The Alignment parameter is a nonzero integral multiple of D'Alignment if D is a specific type, and otherwise is a nonzero integral multiple the alignment of the specific type identified by the tag of the object being created. Please speak up if you (or anyone) disagrees for some reason. (It's been a year and a half; everyone should have changed their minds by now... :-) **************************************************************** From: Alan Burns Sent: Monday, September 19, 2011 4:51 AM We have just held IRTAW - lots of interesting stuff for post Ada2012! But a couple of 'editorial' issues were noted with regard to D.16.1 package System.Multiprocessors.Dispatching_Domain has pragma Preelaborate. But it also withs Ada.Real-Time that does not have this pragma. This seems to be wrong. ... [Rest omitted here, in AI05-0278-1.] **************************************************************** From: Brad Moore Sent: Wednesday, December 28, 2011 10:29 AM [Part of a larger review... - Editor] A.18.18 (73.a.1/3) Delete this paragraph, it is almost identical to the preceding paragraph, and the 'Implementation Advice' tag is also redundant, since it falls under the 'Implementation Advice' section. ... If the preceding paragraphs are necessary, then there is a consistency problem, because some of the containers do not have these redundant paragraphs. **************************************************************** From: Randy Brukardt Sent: Friday, December 30, 2011 11:38 PM > A.18.18 (73.a.1/3) Delete this paragraph, it is almost identical to > the preceding paragraph, and the 'Implementation Advice' tag is also > redundant, since it falls under the 'Implementation Advice' section. This is the "marker" note for the what becomes the contents of the Implementation Advice annex (which is automatically generated from these notes). We could consider suppressing these globally (so they aren't shown at all), but doing so would change the paragraph numbers of some AARM notes silently, so that would not be a great idea. ... > If the preceding paragraphs are necessary, then there is a consistency > problem, because some of the containers do not have these redundant > paragraphs. Anything that doesn't have these paragraphs won't show up in the Annex (M.3), which would be a fairly serious bug. There should be one after every implementation advice (or some other note stating that we don't want an annex entry, there is a couple of cases of that). I can't find any missing ones on a quicky random check. If you can, please tell me so that I can fix them somehow. **************************************************************** From: Brad Moore Sent: Saturday, December 31, 2011 10:22 AM The inconsistent containers are ; A.18.22 The Generic Package Containers.Bounded_Ordered_Maps A.18.24 The Generic Package Containers.Bounded_Ordered_Sets **************************************************************** From: Randy Brukardt Sent: Saturday, December 31, 2011 5:25 PM Ah, I see that's intentional, because the wording of the Implementation Advice is identical to the hashed versions. It would look insane to repeat that wording twice in a row in the annex. There should have been a comment in the code (rather than just in the source, where there is one), so you could see why it is omitted. Arguably, omitting these is a bad idea because the section reference is missed in the annex. In that case, we need to change the (normative) wording of all four sets of this advice to add "ordered" and "hashed" appropriately. Should we do that? What do you think? **************************************************************** From: Brad Moore Sent: Tuesday, January 3, 2012 12:22 PM Definitely not a high priority issue, but if it's not too much trouble, I think it would be good to make the changes in the name of consistency, otherwise it looks like an omission. **************************************************************** From: Steve Baird Sent: Monday, January 9, 2012 3:43 PM [Part of a larger review... - Editor] Oh dear. I read 13.11.3 and became very confused. It isn't at all clear for which entities the Default_Storage_Pool aspect may be specified. 5/3 says The language-defined aspect Default_Storage_Pool may be used to define the default pool for access types within an instance. Is this a roundabout way of saying that this aspect may be specified for an instance? It reads like non-normative introductory text. More precise wording is definitely needed, especially when we are doing non-intuitive things like allowing it to be specified via an aspect definition clause for an instance, but only via a pragma for a generic. Or something like that. I can't tell. Did we lose a paragraph or something? **************************************************************** From: Randy Brukardt Sent: Friday, January 13, 2012 1:22 AM ... > Is this a roundabout way of saying that this aspect may be > specified for an instance? Yes (I think). The AARM notes explain the intended model, but I agree that the normative wording ought to match. > It reads like non-normative introductory text. > More precise wording is definitely needed, especially when we > are doing non-intuitive things like allowing it to be > specified via an aspect definition clause for an instance, > but only via a pragma for a generic. Or something like that. > I can't tell. > > Did we lose a paragraph or something? No, that's the wording in the original AI. So it is more that the text was never there. I don't think much additional is actually needed, add a second sentence: "The aspect can be specified for a generic instance". Or maybe it is better to just change the first sentence: The language-defined aspect Default_Storage_Pool may be {specified for a generic instance; it defines} [used to define] the default pool for access types within an instance. **************************************************************** From: Randy Brukardt Sent: Saturday, February 3, 2012 12:35 AM 7.3.2(14-15/3) says: Upon successful return from a call on any subprogram or entry that: *is explicitly declared within the immediate scope of type T (or by an instance of a generic unit, and the generic is declared within the immediate scope of type T), and Erhard points out (in a very convoluted way, unfortunately, I wasted 20 minutes writing an explanation before stumbling onto his point), that this means that implicitly declared subprograms, like inherited primitives, aren't covered by invariant checks "on the way back". And this means that 7.3.2(22/3) is a lie, which is surely not our intent. I can't find any reason for the "explicitly" in this bullet, so I've just deleted it, in which case the rules work and the note is true. But I worry that it was there for some good reason. If the reason was to avoid wrappers, well, we decided that we didn't want to do that (as evidenced by the 7.3.2(22/3) note), so then the word is just wrong. If there was any other reason, I can't figure it out, and I didn't find anything in the AIs to help. Anyone else remember? (Tucker in particular.) More generally, anyone know of a reason not to delete this stray "explicitly"? ****************************************************************