CVS difference for ai12s/ai12-0442-1.txt

Differences between 1.2 and version 1.3
Log of other versions for file ai12s/ai12-0442-1.txt

--- ai12s/ai12-0442-1.txt	2022/05/07 06:14:18	1.2
+++ ai12s/ai12-0442-1.txt	2022/06/14 23:39:33	1.3
@@ -1,4 +1,4 @@
-!standard 3.4(34)                                       22-05-05  AI12-0442-1/02
+!standard 3.4(34)                                       22-05-25  AI12-0442-1/03
 !standard 3.5(58)
 !standard 3.5.5(12)
 !standard 3.5.9(22)
@@ -15,7 +15,7 @@
 !standard 5.2.1(8/5)
 !standard 5.5(14)
 !standard 6.1.1(43/3)
-!standard 6.1.2(18/5)
+!standard 6.1.2(44/5)
 !standard 7.3(18)
 !standard 7.3(20/2)
 !standard 7.3(20.1/2)
@@ -30,6 +30,7 @@
 !standard 9.7.4(13)
 !standard 9.8(22)
 !standard 9.9(7)
+!standard 9.9(8)
 !standard 10.1.1(27)
 !standard 10.1.4(9)
 !standard 10.2(34)
@@ -43,7 +44,7 @@
 !standard 12.5.2(9)
 !standard 12.6(11)
 !standard 12.6(16.1/2)
-!standard 13.4(11/3)
+!standard 13.4(11/5)
 !standard 13.9.2(14/2)
 !standard 13.11(26)
 !standard 13.11.4(33/3)
@@ -66,6 +67,10 @@
 !standard E.2.2(18)
 !standard E.4.2(12)
 !standard H.5(7/2)
+!standard M(1/3)
+!standard M.1(1/2)
+!standard M.2(1/2)
+!standard M.3(1/2)
 !class presentation 22-04-25
 !status Amendment 1-2012 22-05-05
 !status ARG Approved 14-0-0  22-05-05
@@ -113,8 +118,7 @@
     NOTE 2   For a subtype of a scalar type, the result delivered by the
     attributes Succ, Pred, and Value {can be outside}[might not belong to]
     the subtype; similarly, the actual parameters of the attributes Succ,
-    Pred, and Image {are also allowed to be outside}[need not belong to]
-    the subtype.
+    Pred, and Image {can also be outside}[need not belong to] the subtype.
 
 ["Might not" and "need not" are both on the ISO list (as opposed to the
 Directives). AI12-0445-1 now defines "outside" for this use (it already appeared
@@ -124,8 +128,8 @@
 
     NOTE 4   For a subtype of a discrete type, the result delivered by the
     attribute Val {can be outside}[might not belong to] the subtype;
-    similarly, the actual parameter of the attribute Pos {is also allowed
-    to be outside}[need not belong to] the subtype. The following relations
+    similarly, the actual parameter of the attribute Pos {can also 
+    be outside}[need not belong to] the subtype. The following relations
     are satisfied (in the absence of an exception) by these attributes:
 
 ["Might not" and "need not" are both on the ISO list; see 3.5 above - Editor.]
@@ -145,7 +149,7 @@
     have a signed 16-bit representation, using 1 bit for the sign and
     15 bits for fraction, resulting in a base range of -1.0 .. 1.0-2.0**(-15).
 
-[Replace "could have" - Editor.]
+[Replace "could" - Editor.]
 
 Modify 3.6.1(12):
 
@@ -170,10 +174,10 @@
     {can}[could then] derive various (nonabstract) extensions of the type,
     representing alternative implementations of a set. One {possibility 
     is to}[might] use a bit vector, but impose an upper bound on the largest
-    element representable, while another possible implementation is a hash
-    table, trading off space for flexibility.
+    element representable, while another {possible implementation 
+    is}[might use] a hash table, trading off space for flexibility.
 
-[Replace "might" and "could" - Editor.]
+[Replace "might" (twice) and "could" - Editor.]
 
 Modify 3.9.4(26/2):
 
@@ -192,6 +196,15 @@
 [Replacement for "May, "need not", "must", "could be" - this paragraph has 
 everything we're not supposed to say! - Editor.]
 
+Modify 3.9.4(33/2):
+
+   An interface such as Queue can be used directly as the parent of a new type
+   (as shown here), or can be used as a progenitor when a type is derived. In
+   either case, the primitive operations of the interface are inherited. For
+   Queue, the implementation of the four inherited routines {will be required
+   to}[must] be provided. Inside the call of Transfer, calls will dispatch to
+   the implementations of Append and Remove_First for type Fast_Food_Queue.
+
 Modify 3.10.2(39):
 
     NOTE 7   An implementation {can}[may] consider two access-to-subprogram
@@ -276,17 +289,10 @@
 
 ["need not" is replaced - Editor.]
 
-Modify 6.1.2(18/5):
+Modify 6.1.2(44/5):
 
-   The Global aspect for a callable entity defines the global variables that
-   {can}[might] be referenced as part of a call on the entity, including any
-   assertion expressions that apply to the call (even if not enabled),
-   {such as}[including] preconditions, postconditions, predicates, and type
-   invariants.
-
-["including" is given twice here, I recommend changing the second one as
-marked. It's annoying to re-read wording 'cause one sees mistakes never
-before seen. - Editor.]
+    NOTE   For an example of the use of these aspects[ and attributes], see
+    the Vector container definition in A.18.2.
 
 Modify 7.3(18):
 
@@ -447,6 +453,15 @@
 
 [Another usage recommendation (see 3.9 note) - Editor.]
 
+Modify 9.9(8):
+
+    NOTE 3   Within protected units, {by}[algorithms] interrogating the
+    attribute E'Count in the entry_barrier for the entry E {an algorithm
+    can}[should take precautions to] allow for the evaluation of the
+    condition of the barrier both before and after queuing a given caller. 
+
+[Another usage recommendation (see 3.9 note) - Editor.]
+
 Modify 10.1.1(27):
 
     NOTE 1   A simple program {can}[may] consist of a single compilation unit.
@@ -602,7 +617,7 @@
 
 [Replace "must" - Editor.]
 
-Modify 13.4(11/3):
+Modify 13.4(11/5):
 
     NOTE   Attribute Enum_Rep {can}[may] be used to query the internal codes
     used for an enumeration type; attribute Enum_Val {can}[may] be used to
@@ -698,16 +713,65 @@
     more portable if they}[Portable applications should] assume
     that these values, or values sufficiently close to them to behave
     indistinguishably from them, can occur. If a sequence of random
-    integers from some fixed range is {necessary}[needed], the application
-    should use the Random function in an appropriate instantiation of
-    Numerics.Discrete_Random, rather than transforming the result of the
-    Random function in Numerics.Float_Random. However, some applications
+    integers from some [fixed ]range is {necessary}[needed], {it is
+    preferred that }the application [should use]{uses one of} the
+    Random function{s} in an appropriate
+    instantiation of Numerics.Discrete_Random, rather than transforming
+    the result of the Random function in Numerics.Float_Random.[ However,
+    some applications
     with unusual requirements, such as for a sequence of random integers
     each drawn from a different range, will find it more convenient to
     transform the result of the floating point Random function. For M >=
-    1, the expression
+    1, the expression]
+
+[Replace "may or may not", "should", "need". This includes a usage 
+recommendation, see the note at 3.9. See below for why we're deleting
+the "however" part. - Editor.]
+
+Delete A.5.2(51).
+
+Modify A.5.2(52):
+
+   {AARM Reason: One might think that a simple transformation of the
+   result of the floating point Random function such as 
+   Integer(Float(M) * Random(G)) mod M)
+   would give a uniform distribution. But this is only true if the period
+   of the underlying generator is a multiple of M. (This usually requires
+   that M be a power of two.) In other cases, the mod operation maps slightly
+   more random values to a some result values than others. It is easy to see
+   this: consider a 4-bit random integer (with a range of 0 .. 15). If one mods
+   this by 6 to get a value in 0 .. 5 (to which one would add 1 to get the
+   value of a die roll), 3 values would be mapped to each value 0 .. 3, but
+   only 2 values would be mapped to 4 and 5. Even when the input is uniformly
+   distributed, the output clearly is not. A similar effect occurs
+   regardless of the number of bits in the random integer. Since it takes
+   care to get this right, users should use the provided functions (which
+   presumably do this correctly - AI12-0144-1 contains a correct algorithm)
+   and resist the urge to "roll-their-own".}
+
+   {NOTE 4: }[transforms the result of Random(G) to an integer uniformly
+   distributed over the range 0 .. M–1; it is valid even if Random delivers
+   0.0 or 1.0. Each value of the result range is possible, provided that M
+   is not too large. ]Exponentially distributed (floating point) random numbers
+   with mean and standard deviation 1.0 can be obtained by the transformation    
+
+[We delete the text about tranforming the result of the float random to get
+uniformly distributed integers. There are two problems with this:
+
+   * First, since AI12-0144-1 added a dedicated routine to handle the supposed
+     "unusual requirement" as described here, it doesn't make sense to explain
+     a different way to do that operation.
+
+  * Second, the given transformation does not provide a uniformly distributed
+    result unless M is a power of two (on a 2's complement machine). The result
+    is close to uniformly distributed, but the difference can matter if enough
+    random values are generated. (The new AARM note attempts to explain why.)
+    The newly provided function presumably does give a true uniform
+    distribution (assuming the underlying generator does) - AI12-0144-1 gives
+    a correct algorithm used in an open source SSH implementation - so it is
+    way better to use that.
 
-[Replace "may or may not", "should", "need" - Editor.]
+- Editor.]
 
 Modify A.16(127/2):
 
@@ -737,7 +801,6 @@
     exist. Name_Error is raised only as specified or if the file name is
     malformed and cannot possibly identify a file. The result of these
     operations depends only on their parameters.
-
 ["need" is replaced - Editor.]
 
 Modify A.18.3(164/2):
@@ -813,7 +876,7 @@
 Modify D.3(21):
 
     NOTE 4   When specifying the ceiling of a protected object, [one should
-    choose] a {correct }value that is {one that is }at least as high
+    choose] a {correct }value {is one }that is at least as high
     as the highest active priority
     at which tasks can be executing when they call protected operations of
     that object. In determining this value the following factors, which
@@ -834,15 +897,6 @@
 
 [Reword to eliminate "should" - Editor.]
 
-Modify E.4.2(12):
- 
-  * The Tape_Client procedure references only declarations in the Tapes
-    and Name_Server packages. Before using a tape for the first time, it
-    {will}[needs to] query the Name_Server for a system-wide identity for that
-    tape. From then on, it can use that identity to access the tape device.
-
-[Replace "needs" - Editor.]
-
 Modify E.2.2(18):
 
     NOTE 1   A remote types library unit {is not necessarily}[need not be]
@@ -854,6 +908,15 @@
 
 [Replace "may", "need not" - Editor.]
 
+Modify E.4.2(12):
+ 
+  * The Tape_Client procedure references only declarations in the Tapes
+    and Name_Server packages. Before using a tape for the first time, it
+    {will}[needs to] query the Name_Server for a system-wide identity for that
+    tape. From then on, it can use that identity to access the tape device.
+
+[Replace "needs" - Editor.]
+
 Modify H.5(7/2):
 
     NOTE   An operation that causes a task to be blocked within a foreign
@@ -862,6 +925,34 @@
 
 [Replace "need not" - Editor.]
 
+Modify M(1/3):
+
+The Ada language allows for certain target machine dependences in a controlled
+manner. Each Ada implementation {is required to}[must] document many
+characteristics and properties of the target system. This Reference Manual
+contains specific documentation requirements. In addition, many characteristics
+that require documentation are identified throughout this Reference Manual as
+being implementation defined. Finally, this Reference Manual requires
+documentation of whether implementation advice is followed. The following
+subclauses provide summaries of these documentation requirements.
+
+Modify M.1(1/2):
+
+In addition to implementation-defined characteristics, each Ada implementation
+{is required to}[must] document various properties of the implementation: 
+
+Modify M.2(1/2):
+
+The Ada language allows for certain machine dependences in a controlled manner.
+Each Ada implementation {is required to}[must] document all
+implementation-defined characteristics: 
+
+Modify M.3(1/2):
+
+This Reference Manual sometimes gives advice about handling certain target
+machine dependences. Each Ada implementation {is required to}[must] document
+whether that advice is followed: 
+
 [The !appendix has several further occurrences of the unallowed words that we
 are not proposing to change at this time, and why we think no change is
 needed - Editor.]
@@ -950,6 +1041,553 @@
 standard) is preferred so long as we have a rewording that
 does not clearly alter the meaning or harm the understandability of the text.
 
+!comment Only a few changes are defined with Corrigendum sections.
+
+!corrigendum 3.5.5(12)
+
+@drepl
+@xindent<@s9<NOTE 4 @  For a subtype of a discrete type, the result delivered
+by the attribute Val might not belong to the subtype;
+similarly, the actual parameter of the attribute Pos need not belong to the
+subtype. The following relations are satisfied (in the absence of an
+exception) by these attributes:>>
+@dby
+@xindent<@s9<NOTE 4 @  For a subtype of a discrete type, the result delivered
+by the attribute Val can be outside the subtype; similarly, the actual
+parameter of the attribute Pos can also be outside the subtype. The following
+relations are satisfied (in the absence of an exception) by these attributes:>>
+
+!corrigendum 3.5.9(22)
+
+@drepl
+@xindent<@s9<NOTE @  The base range of an ordinary fixed point type need not
+include the specified bounds themselves so that the range specification can be
+given in a natural way, such as:>>
+@dby
+@xindent<@s9<NOTE @  The specified bounds themselves can be outside the base
+range of an ordinary fixed point type so that the range specification can be
+given in a natural way, such as:>>
+
+!corrigendum 3.5.9(24)
+
+@drepl
+@xindent<@s9<With 2's complement hardware, such a type could
+have a signed 16-bit representation, using 1 bit for the sign and
+15 bits for fraction, resulting in a base range of -1.0 .. 1.0-2.0**(-15).>>
+@dby
+@xindent<@s9<With 2's complement hardware, such a type would typically
+have a signed 16-bit representation, using 1 bit for the sign and
+15 bits for fraction, resulting in a base range of -1.0 .. 1.0-2.0**(-15).>>
+
+!corrigendum 3.9.4(26/2)
+
+@drepl
+This defines a Queue interface defining a queue of people. (A similar
+design could be created to define any kind of queue simply by replacing
+Person_Name by an appropriate type.)
+The Queue interface has four dispatching operations, Append,
+Remove_First, Cur_Count, and Max_Count. The body of a class-wide
+operation, Transfer is also shown. Every non-abstract extension
+of Queue must provide implementations for at least its four
+dispatching operations, as they are abstract. Any object of a type
+derived from Queue may be passed to Transfer as either the From
+or the To operand. The two operands need not be of the same type
+in any given call.
+@dby
+This defines a Queue interface defining a queue of people. (A similar
+design is possible to define any kind of queue simply by replacing
+Person_Name by an appropriate type.)
+The Queue interface has four dispatching operations, Append,
+Remove_First, Cur_Count, and Max_Count. The body of a class-wide
+operation, Transfer is also shown. Every nonabstract extension
+of Queue will provide implementations for at least its four
+dispatching operations, as they are abstract. Any object of a type
+derived from Queue can be passed to Transfer as either the From or
+the To operand. The two operands can be of different types in a given call.
+
+!corrigendum 3.9.4(33/2)
+
+@drepl
+An interface such as Queue can be used directly as the parent of a new type
+(as shown here), or can be used as a progenitor when a type is derived. In
+either case, the primitive operations of the interface are inherited. For
+Queue, the implementation of the four inherited routines
+must be provided. Inside the call of Transfer, calls will dispatch to
+the implementations of Append and Remove_First for type Fast_Food_Queue.
+@dby
+An interface such as Queue can be used directly as the parent of a new type
+(as shown here), or can be used as a progenitor when a type is derived. In
+either case, the primitive operations of the interface are inherited. For
+Queue, the implementation of the four inherited routines will be required
+to be provided. Inside the call of Transfer, calls will dispatch to
+the implementations of Append and Remove_First for type Fast_Food_Queue.
+
+!corrigendum 4.3.5(0)
+
+@dinsc
+See the conflict file for the changes.
+
+!corrigendum 5.1(15)
+
+@dinsa
+The execution of a @fa<sequence_of_statements> consists of the execution of 
+the individual @fa<statement>s in succession until the @fa<sequence_> is 
+completed. 
+@dinss
+Within a parallel construct, if a transfer of control out of the
+construct is initiated by one of the logical threads of control, an
+attempt is made to @i<cancel> all other logical threads of control
+initiated by the parallel construct. Once all other logical threads of
+control of the construct either complete or are canceled, the transfer
+of control occurs. If two or more logical threads of control of the
+same construct initiate such a transfer of control concurrently, one
+of them is chosen arbitrarily and the others are canceled.
+
+When a logical thread of control is canceled, the cancellation causes
+it to complete as though it had performed a transfer of control to the
+point where it would have finished its execution. Such a cancellation
+is deferred while the logical thread of control is executing within an
+abort-deferred operation (see 9.8), and may be deferred further, but
+not past a point where the logical thread initiates a new nested
+parallel construct or reaches an exception handler that is outside
+such an abort-deferred operation.
+
+@s8<@i<Bounded (Run-Time) Errors>>
+
+During the execution of a parallel construct, it is a bounded error to
+invoke an operation that is potentially blocking (see 9.5).
+Program_Error is raised if the error is detected by the
+implementation; otherwise, the execution of the potentially blocking
+operation can either proceed normally, or it can result in the indefinite
+blocking of some or all of the logical threads of control making up
+the current task.
+
+!corrigendum 5.2.1(0)
+
+@dinsc
+See the conflict file for the changes.
+
+!corrigendum 6.1.2(0)
+
+@dinsc
+See the conflict file for the changes.
+
+!corrigendum 9.1(21/2)
+
+@drepl
+@xindent<@s9<NOTE 3 @  A task type is a limited type (see 7.5), and hence precludes
+use of @fa<assignment_statement>s and predefined equality operators. If an
+application needs to store and exchange task identities, it can do so by
+defining an access type designating the corresponding task objects and by using
+access values for identification purposes. Assignment is available for such an
+access type as for any access type. Alternatively, if the implementation
+supports the Systems Programming Annex, the Identity attribute can be used for
+task identification (see C.7.1).>>
+@dby
+@xindent<@s9<NOTE 3 @  A task type is a limited type (see 7.5), and hence precludes
+use of @fa<assignment_statement>s and predefined equality operators. If a
+programmer wants to write an application that stores and exchanges task
+identities, they can do so by defining an access type designating the 
+corresponding task objects and by using
+access values for identification purposes. Assignment is available for such an
+access type as for any access type. Alternatively, if the implementation
+supports the Systems Programming Annex, the Identity attribute can be used for
+task identification (see C.7.1).>>
+
+!corrigendum 9.6.1(90/2)
+
+@drepl
+@xindent<@s9<NOTE 1 @  The implementation-defined time zone of package Calendar
+may, but need not, be the local time zone. UTC_Time_Offset always returns the
+difference relative to the implementation-defined time zone of package
+Calendar. If UTC_Time_Offset does not raise Unknown_Zone_Error, UTC time
+can be safely calculated (within the accuracy of the underlying time-base).>>
+@dby
+@xindent<@s9<NOTE 1 @  The implementation-defined time zone of package Calendar
+can be the local time zone. Local_Time_Offset always returns the
+difference relative to the implementation-defined time zone of package
+Calendar. If Local_Time_Offset does not raise Unknown_Zone_Error, UTC time
+can be safely calculated (within the accuracy of the underlying time-base).>>
+
+!corrigendum 9.9(7)
+
+@drepl
+@xindent<@s9<NOTE 2 @  Within task units, algorithms interrogating the attribute
+E'Count should take precautions to allow for the
+increase of the value of this attribute for incoming entry calls,
+and its decrease, for example with @fa<timed_entry_call>s. Also, a
+@fa<conditional_entry_call> may
+briefly increase this value, even if the conditional call is not accepted.>>
+@dby
+@xindent<@s9<NOTE 2 @  Within task units, by interrogating the attribute
+E'Count an algorithm can allow for the increase of the value of this attribute
+for incoming entry calls, and its decrease, for example with
+@fa<timed_entry_call>s. A @fa<conditional_entry_call> can also
+briefly increase this value, even if the conditional call is not accepted.>>
+
+!corrigendum 9.9(8)
+
+@drepl
+@xindent<@s9<NOTE 3 @  Within protected units, algorithms interrogating the
+attribute E'Count in the entry_barrier for the entry E 
+should take precautions to allow for the evaluation of the
+@fa<condition> of the barrier both before and after queuing a given caller.>>
+@dby
+@xindent<@s9<NOTE 3 @  Within protected units, by interrogating the
+attribute E'Count in the entry_barrier for the entry E an algorithm
+can allow for the evaluation of the
+@fa<condition> of the barrier both before and after queuing a given caller.>>
+
+
+!corrigendum 10.1.1(27)
+
+@drepl
+@xindent<@s9<NOTE 1 @  A simple program may consist of a single compilation
+unit. A @fa<compilation> need not have any compilation units; for example,
+its text can consist of @fa<pragma>s.>>
+@dby
+@xindent<@s9<NOTE 1 @  A simple program can consist of a single
+compilation unit. A @fa<compilation> can have no compilation units; for
+example, its text can consist of @fa<pragma>s.>>
+
+!corrigendum 10.1.4(9)
+
+@drepl
+@xindent<@s9<NOTE 2 @  An implementation may support a concept of a @i<library>,
+which contains @fa<library_item>s. If multiple libraries are supported, the
+implementation has to define how a single environment
+is constructed when a compilation unit is submitted to the compiler. 
+Naming conflicts between different libraries might
+be resolved by treating each library
+as the root of a hierarchy of child library units.>>
+@dby
+@xindent<@s9<NOTE 2 @  An implementation can support a concept of a @i<library>,
+which contains @fa<library_item>s. If multiple libraries are supported, the
+implementation can document how a single environment
+is constructed when a compilation unit is submitted to the compiler. 
+Naming conflicts between different libraries can, for example,
+be resolved by treating each library as the root of a hierarchy of child
+library units.>>
+
+!corrigendum 10.2(34)
+
+@drepl
+@xindent<@s9<NOTE 4 @  A partition (active or otherwise) need
+not have a main subprogram. In such a case, all the work done by the 
+partition would be done by elaboration of various @fa<library_item>s, and by
+tasks created by that elaboration. Passive partitions, which cannot have
+main subprograms, are defined in Annex E, "Distributed Systems".>>
+@dby
+@xindent<@s9<NOTE 4 @  A partition (active or otherwise) does not necessarily
+have a main subprogram. In such a case, all the work done by the 
+partition would be done by elaboration of various @fa<library_item>s, and by
+tasks created by that elaboration. Passive partitions, which cannot have
+main subprograms, are defined in Annex E, "Distributed Systems".>>
+
+!corrigendum 11.5(29)
+
+@drepl
+@xindent<@s9<NOTE 1 @  There is no guarantee that a suppressed check is
+actually removed; hence a @fa<pragma> Suppress should be used only for
+efficiency reasons.>>
+@dby
+@xindent<@s9<NOTE 1 @  There is no guarantee that a suppressed check is
+actually removed; hence a @fa<pragma> Suppress is useful only to improve
+efficiency.>>
+
+!corrigendum 12.5.5(5/2)
+
+@dinsb
+@xcode<@b<type> Root_Work_Item @b<is tagged private>;>
+@dinst
+@i<Example of the use of a generic with a formal interface type, to establish 
+a standard interface that all tasks will implement so they can be managed
+appropriately by an application-specific scheduler:>
+
+!corrigendum 12.6(11)
+
+@drepl
+@xindent<@s9<NOTE 1 @  The matching rules for formal subprograms state
+requirements that are similar to those applying to
+@fa<subprogram_renaming_declaration>s (see 8.5.4). In particular, the name 
+of a parameter of the formal subprogram [need not be the same as that of the
+corresponding parameter of the actual subprogram; similarly, for these 
+parameters, @fa<default_expression>s need not correspond.>>
+@dby
+@xindent<@s9<NOTE 1 @  The matching rules for formal subprograms state
+requirements that are similar to those applying to
+@fa<subprogram_renaming_declaration>s (see 8.5.4). In particular, the name 
+of a parameter of the formal subprogram can be different from that of the
+corresponding parameter of the actual subprogram; similarly, for these 
+parameters, @fa<default_expression>s can be different.>>
+
+!corrigendum 12.6(16.1/2)
+
+@drepl
+@xindent<@s9<NOTE 7 @  The subprogram declared by a 
+@fa<formal_abstract_subprogram_declaration> is an abstract subprogram. All
+calls on a subprogram declared by a @fa<formal_abstract_subprogram_declaration>
+must be dispatching calls. See 3.9.3.>>
+@dby
+@xindent<@s9<NOTE 7 @  The subprogram declared by a 
+@fa<formal_abstract_subprogram_declaration> is an abstract subprogram. All
+calls on a subprogram declared by a @fa<formal_abstract_subprogram_declaration>
+are limited to dispatching calls. See 3.9.3.>>
+
+!corrigendum 13.4(11/5)
+
+@drepl
+@xindent<@s9<NOTE @  Attribute Enum_Rep may be used to query the internal codes
+used for an enumeration type; attribute Enum_Val may be used to
+convert from an internal code to an enumeration value. The other
+attributes of the type, such as Succ, Pred, and Pos, are unaffected by
+the @fa<enumeration_representation_clause>. For example, Pos always
+returns the position number, not the internal integer code that
+might have been specified in an @fa<enumeration_representation_clause>.>>
+@dby
+@xindent<@s9<NOTE @  Attribute Enum_Rep can be used to query the internal codes
+used for an enumeration type; attribute Enum_Val can be used to
+convert from an internal code to an enumeration value. The other
+attributes of the type, such as Succ, Pred, and Pos, are unaffected by
+an @fa<enumeration_representation_clause>. For example, Pos always
+returns the position number, not {an}[the] internal integer code that
+{was}[might have been] specified in an @fa<enumeration_representation_clause>.>>
+
+!corrigendum 13.9.2(14/2)
+
+@drepl
+@xindent<@s9<NOTE 3 @  The Valid attribute may be used to check the result of
+calling an instance of Unchecked_Conversion (or any other operation
+that can return invalid values). However, an exception handler 
+should also be provided because implementations are
+permitted to raise Constraint_Error or Program_Error if they detect
+the use of an invalid representation (see 13.9.1).>>
+@dby
+@xindent<@s9<NOTE 3 @  The Valid attribute can be used to check the result of
+calling an instance of Unchecked_Conversion (or any other operation
+that can return invalid values). However, an exception handler is
+still useful because implementations are
+permitted to raise Constraint_Error or Program_Error if they detect
+the use of an invalid representation (see 13.9.1).>>
+
+!corrigendum 13.11(26)
+
+@drepl
+@xindent<@s9<NOTE 1 @  A user-defined storage pool type can be obtained by
+extending the Root_Storage_Pool type, and overriding the primitive subprograms
+Allocate, Deallocate, and Storage_Size. A user-defined storage pool
+can then be obtained by declaring an object of the type extension. The
+user can override Initialize and Finalize if there is any need
+for nontrivial initialization and finalization for a user-defined pool
+type. For example, Finalize might reclaim blocks of storage that
+are allocated separately from the pool object itself.>>
+@dby
+@xindent<@s9<NOTE 1 @  A user-defined storage pool type can be obtained by
+extending the Root_Storage_Pool type, and overriding the primitive subprograms
+Allocate, Deallocate, and Storage_Size. A user-defined storage pool
+can then be obtained by declaring an object of the type extension. The
+user can override Initialize and Finalize if there is any desire
+for nontrivial initialization and finalization for a user-defined pool
+type. For example, Finalize can reclaim blocks of storage that
+are allocated separately from the pool object itself.>>
+
+!corrigendum 13.11.4(33/3)
+
+@drepl
+@xindent<@s9<NOTE 1 @  A user-defined storage pool type that supports subpools
+can be implemented by extending the Root_Storage_Pool_With_Subpools type,
+and overriding the primitive subprograms Create_Subpool,
+Allocate_From_Subpool, and Deallocate_Subpool. Create_Subpool 
+should call Set_Pool_Of_Subpool before returning the 
+subpool handle. To make use of such a pool, a user would declare an
+object of the type extension, use it to define the Storage_Pool 
+attribute of one or more access types, and then call Create_Subpool
+to obtain subpool handles associated with the pool.>>
+@dby
+@xindent<@s9<NOTE 1 @  A user-defined storage pool type that supports subpools can
+be implemented by extending the Root_Storage_Pool_With_Subpools type,
+and overriding the primitive subprograms Create_Subpool,
+Allocate_From_Subpool, and Deallocate_Subpool. Create_Subpool is 
+expected to call Set_Pool_Of_Subpool before returning the 
+subpool handle. To make use of such a pool, a user can declare an
+object of the type extension, use it to define the Storage_Pool 
+attribute of one or more access types, and then call Create_Subpool
+to obtain subpool handles associated with the pool.>>
+
+!corrigendum 13.11.4(35/3)
+
+@drepl
+@xindent<@s9<NOTE 3 @  The pool implementor should override 
+Default_Subpool_For_Pool if {they want} the pool is to support a default
+subpool for the pool. The implementor can override Deallocate if individual
+object reclamation is to be supported, and can override Storage_Size if there
+is some limit on the total size of the storage pool. The implementor can
+override Initialize and Finalize if there is any need for nontrivial
+initialization and finalization for the pool as a whole. For example,
+Finalize might reclaim blocks of storage that are allocated over and
+above the space occupied by the pool object itself. The pool
+implementor may extend the Root_Subpool type as necessary to carry
+additional information with each subpool provided by Create_Subpool.>>
+@dby
+@xindent<@s9<NOTE 3 @  The pool implementor can override 
+Default_Subpool_For_Pool if they want the pool to support a default
+subpool for the pool. The implementor can override Deallocate if individual
+object reclamation is to be supported, and can override Storage_Size if there
+is some limit on the total size of the storage pool. The implementor can
+override Initialize and Finalize if there is any desire for nontrivial
+initialization and finalization for the pool as a whole. For example,
+Finalize can reclaim blocks of storage that are allocated over and
+above the space occupied by the pool object itself. The pool
+implementor can extend the Root_Subpool type as necessary to carry
+additional information with each subpool provided by Create_Subpool.>>
+
+!corrigendum 13.13.2(57)
+
+@drepl
+@xindent<@s9<NOTE 1 @  For a definite subtype S of a type @i<T>, only
+@i<T>'Write and @i<T>'Read are needed to pass an arbitrary value of the subtype
+through a stream. For an indefinite subtype S of a type @i<T>, @i<T>'Output
+and @i<T>'Input will normally be needed, since @i<T>'Write and 
+@i<T>'Read do not pass bounds, discriminants, or tags.>>
+@dby
+@xindent<@s9<NOTE 1 @  For a definite subtype S of a type @i<T>, only
+@i<T>'Write and @i<T>'Read are necessary to pass an arbitrary value of the
+subtype through a stream. For an indefinite subtype S of a type @i<T>,
+@i<T>'Output and @i<T>'Input will normally be necessary, since
+@i<T>'Write and  @i<T>'Read do not pass bounds, discriminants, or tags.>>
+
+
+!corrigendum A.4.3(107/3)
+
+@drepl
+@xindent<@s9<NOTE 1 @  In the Index and Count functions taking Pattern and
+Mapping parameters, the actual String parameter passed to Pattern should
+comprise characters occurring as target characters of the mapping.
+Otherwise, the pattern will not match.>>
+@dby
+@xindent<@s9<NOTE 1 @  In the Index and Count functions taking Pattern and
+Mapping parameters, for there to be a match, the actual String parameter
+passed to Pattern can contain only characters occurring as target characters
+of the mapping.>>
+
+!corrigendum A.5.2(50)
+
+@drepl
+@xindent<@s9<NOTE 3 @  A given implementation of the Random function in
+Numerics.Float_Random may or may not be capable of delivering the values
+0.0 or 1.0. Portable applications should assume that these values, or values
+sufficiently close to them to behave indistinguishably from them, can occur.
+If a sequence of random integers from some fixed range is needed, the
+application should use the Random function in an appropriate instantiation
+of Numerics.Discrete_Random, rather than transforming the result of the Random
+function in Numerics.Float_Random. However, some applications with unusual
+requirements, such as for a sequence of random integers each drawn from a
+different range, will find it more convenient to transform the result of the
+floating point Random function. For M @>= 1, the expression>>
+@dby
+@xindent<@s9<NOTE 3 @  A given implementation of the Random function in
+Numerics.Float_Random is not guaranteed to be capable of delivering the
+values 0.0 or 1.0. Applications will be more portable if they assume
+that these values, or values sufficiently close to them to behave
+indistinguishably from them, can occur. If a sequence of random
+integers from some range is necessary, it is preferred that the application
+uses one of the Random functions in an appropriate
+instantiation of Numerics.Discrete_Random, rather than transforming
+the result of the Random function in Numerics.Float_Random.>>
+
+!corrigendum A.16(131/2)
+
+@drepl
+@xindent<@s9<NOTE 5 @  To move a file or directory to a different location,
+use Rename. Most target systems will allow renaming of files from one
+directory to another. If the target file or directory might
+already exist, it first.>>
+@dby
+@xindent<@s9<NOTE 5 @  To move a file or directory to a different location,
+use Rename. Most target systems will allow renaming of files from one
+directory to another. If the target file or directory can already exist,
+delete it first.>>
+
+!corrigendum B.3.1(60)
+
+@drepl
+@xbullet<the allocated object should be freed by the programmer via a call
+of Free, not by a called C function.>
+@dby
+@xbullet<the allocated object can be freed by the programmer via a call
+of Free, rather than by calling a C function.>
+
+!corrigendum D.2.5(18/2)
+
+@drepl
+@xindent<@s9<NOTE 1 @  Due to implementation constraints, the quantum value
+returned by Actual_Quantum might not be identical to that set with Set_Quantum.>>
+@dby
+@xindent<@s9<NOTE 1 @  Due to implementation constraints, the quantum value
+returned by Actual_Quantum can differ from that set with Set_Quantum.>>
+
+!corrigendum D.3(21)
+
+@drepl
+@xindent<@s9<NOTE 4 @  When specifying the ceiling of a protected object, 
+one should choose a value that is at least as high as the highest 
+active priority at which tasks can be executing when they call protected
+operations of that object. In determining this value the following factors,
+which can affect active priority, should be considered:
+the effect of Set_Priority, nested protected operations, entry calls,
+task activation, and other implementation-defined factors.>>
+@dby
+@xindent<@s9<NOTE 4 @  When specifying the ceiling of a protected object,
+a correct value is one that is at least as high as the highest active priority
+at which tasks can be executing when they call protected operations of
+that object. In determining this value the following factors, which
+can affect active priority, are relevant:
+the effect of Set_Priority, nested protected operations, entry calls,
+task activation, and other implementation-defined factors.>>
+
+!corrigendum D.5.1(19)
+
+@drepl
+@xindent<@s9<NOTE 5 @  Changing the priorities of a set of tasks can be 
+performed by a series of calls to Set_Priority for each task separately.
+For this to work reliably, it should be done within a protected operation
+that has high enough ceiling priority to guarantee that the operation
+completes without being preempted by any of the affected tasks.>>
+@dby
+@xindent<@s9<NOTE 5 @  Changing the priorities of a set of tasks can be 
+performed by a series of calls to Set_Priority for each task separately.
+This can be done reliably within a protected operation that has high
+enough ceiling priority to guarantee that the operation completes without
+being preempted by any of the affected tasks.>>
+
+!corrigendum E.2.2(18)
+
+@drepl
+@xindent<@s9<NOTE 1 @  A remote types library unit need not be
+pure, and the types it defines may include levels of indirection
+implemented by using access types. User-specified Read and Write
+attributes (see 13.13.2) provide for sending values of such a type
+between active partitions, with Write marshalling the representation,
+and Read unmarshalling any levels of indirection.>>
+@dby
+@xindent<@s9<NOTE 1 @  A remote types library unit is not necessarily
+pure, and the types it defines can include levels of indirection
+implemented by using access types. User-specified Read and Write
+attributes (see 13.13.2) provide for sending values of such a type
+between active partitions, with Write marshalling the representation,
+and Read unmarshalling any levels of indirection.>>
+
+!corrigendum H.5(7/2)
+
+@drepl
+@xindent<@s9<NOTE @  An operation that causes a task to be blocked within a 
+foreign language domain is not defined to be potentially blocking, and need
+not be detected.>>
+@dby
+@xindent<@s9<NOTE @  An operation that causes a task to be blocked within a 
+foreign language domain is not defined to be potentially blocking, and is
+unlikely to be detected.>>
+
 !ASIS
 
 No ASIS effect.
@@ -1000,28 +1638,72 @@
 ["May" should be OK here. I hope. :-)]
 
 
-9.11 Example of Tasking and Synchronization
+E.4.2 Example of Use of a Remote Access-to-Class-Wide Type
 
-                                 Examples
+        -- Tape_Driver is not needed and thus not mentioned in the with_clause
 
-The following example defines a buffer protected object to smooth variations
-between the speed of output of a producing task and the speed of input of some
-consuming task. For instance, the producing task might have the following
-structure:
+[This use of "needed" is a use of a technical term and should not be changed.]
 
-...
+****************************************************************
 
-and the consuming task might have the following structure:
+From: Randy Brukardt
+Sent: Friday, May 6, 2022  11:34 PM
 
-["Might" (in each); but no obvious alternative exists and no one should
-confuse this for any sort of requirement. So I say leave it (the directives
-ban using "might" in a requirement, not banning the word altogether. The
-"House Style" has a stronger statement, but that's only a guideline.)]
+The following items have come up since our meeting yesterday, that either were
+not covered in the AIs or were changed from the AI version because of the "typo"
+comments. Given that time is short before the FDIS needs to be delivered, I will
+go ahead with these items unless someone makes an objection to one of them, in
+which case we'll discuss it here. I'm providing these so there are no surprises.
+
+[Just the cases that are relevant to this AI are shown here - Editor.]
+
+#3 Brad's comment on 9.1(21/2) [AI12-0442-1]:
+
+Brad wrote: "An application can't want things." The original fix was just to
+replace "needs" with "wants", but his point is reasonable (at least for Ada 
+programs :-). So a more extensive fix is needed. Brad's actual suggestion 
+changed from second person to third person in the middle, so I changed his 
+suggestion to the below. I ended up using "they", since ISO doesn't allow 
+gender-specific words or pronouns. "It" doesn't work as we're talking about
+a human now.
 
-E.4.2 Example of Use of a Remote Access-to-Class-Wide Type
+Modify 9.1(21/2):
 
-        -- Tape_Driver is not needed and thus not mentioned in the with_clause
+    NOTE 3   A task type is a limited type (see 7.5), and hence precludes
+    use of assignment_statements and predefined equality operators. If {a
+    programmer wants to write }an application {that stores and 
+    exchanges}[needs to store and exchange] task identities, {they}[it] can
+    do so by defining an access type designating the corresponding task
+    objects and by using access values for identification purposes. Assignment
+    is available for such an access type as for any access type.
+    Alternatively, if the implementation supports the Systems Programming
+    Annex, the Identity attribute can be used for task identification (see
+    C.7.1).
 
-[This use of "needed" is a use of a technical term and should not be changed.]
+----
+
+#4 Jeff's comment on C.7.2(31) [Also AI12-0442-1]
+
+Jeff wrote: "!'m not sure what you're trying to say, I think either the "not" 
+should stay or "until" should become "before", though the former seems more 
+likely." The "not" can't stay, as that would still read like a negative 
+permission (which is not allowed, at least not until the next edition of 
+the Directives).
+
+I didn't think there was any simple fix that made any sense, so I ended up 
+reordering the entire sentence.
+
+Modify C.7.2(31):
+
+    NOTE 1   An attribute always exists (after instantiation), and has the
+    initial value. {An implementation can avoid using}[It need not occupy]
+    memory {to store the attribute value} until the first operation that
+    [potentially] changes the attribute value. The same holds true after
+    Reinitialize.
+
+I dropped "potentially" since this is a runtime action, and thus it would be 
+possible for the implementation to notice the default value being assigned 
+and continue to avoid materializing the attribute. It's already a 
+"possibility" statement because of the "can", we don't have to repeat that.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent