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

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

--- ai12s/ai12-0444-1.txt	2022/05/07 06:14:18	1.3
+++ ai12s/ai12-0444-1.txt	2022/06/14 23:39:33	1.4
@@ -26,6 +26,8 @@
 !standard 10.2.1(11.2/5)
 !standard 11.4.2(27/3)
 !standard 11.6(5)
+!standard 12.5.1(15)
+!standard 13.1(13/5)
 !standard 13.1(22/3)
 !standard 13.1(23/5)
 !standard 13.1(24/3)
@@ -34,13 +36,13 @@
 !standard 13.1(27/3)
 !standard 13.1(28/3)
 !standard 13.2(8/4)
-!standard 13.3(29/2)
-!standard 13.3(30/2)
-!standard 13.3(30.1/2)
-!standard 13.3(33.2/2)
-!standard 13.3(51.2/2)
-!standard 13.3(51.3/2)
-!standard 13.3(65)
+!standard 13.3(31/2)
+!standard 13.3(32/2)
+!standard 13.3(32.1/2)
+!standard 13.3(35.2/2)
+!standard 13.3(56.2/2)
+!standard 13.3(56.3/2)
+!standard 13.3(72)
 !standard 13.4(10)
 !standard 13.5.1(22)
 !standard 13.11(25.4/2)
@@ -71,8 +73,8 @@
 !standard G.1.2(46)
 !standard G.2(3)
 !standard G.3.1(87/2)
-!standard G.3.1(156/2)
-!standard G.3.1(157/2)
+!standard G.3.2(156/2)
+!standard G.3.2(157/2)
 !standard H.7.1(14/5)
 !class presentation 22-04-27
 !status Amendment 1-2012 22-05-05
@@ -151,12 +153,6 @@
 ["Outside" was dubious; we now define it in 3.2(8) {see AI12-0445-1} in
 part to make this sensible - Editor.]
 
-  Alternatively:
-    For the execution of a predefined operation of a signed integer type,
-    {raising}[the implementation need not raise] Constraint_Error {is 
-    required} if the result is outside the base range of the type,
-    {unless}[so long as] the correct result is produced.
-
 Modify 3.5.4(25):
 
     An implementation may provide additional predefined signed integer types,
@@ -168,7 +164,7 @@
     provided) should be no wider than Integer. Corresponding recommendations
     apply to any other predefined integer types. [There need not be a named 
     integer type corresponding to each distinct]{An implementation may support}
-    base range{s} [supported by an implementation] for which there is no
+    base range{s} [supported by an implementation]{for which there is no
     corresponding named integer type}. The range of each first subtype should
     be the base range of its type.
 
@@ -204,13 +200,6 @@
 ["Outside" was dubious; we now define it in 3.2(8) {see AI12-0445-1} in
 part to make this sensible - Editor.]
 
- An alternative update would be:
-   For the execution of a predefined operation of a real type, {raising}
-   [the implementation need not raise] Constraint_Error {is required} if the
-   result is outside the base range of the type, {unless}[so long as] the
-   correct result is produced, or the Machine_Overflows attribute of the type
-   is False (see G.2.1).
-
 Modify 3.5.6(8/5):
 
    An implementation may provide nonstandard real types, descendants of
@@ -297,7 +286,7 @@
 Modify 7.6(19/3):
 
   * If an object is assigned the value of that same object, the
-    implementation [need not do anything]{may omit the assignment}.
+    implementation [need not do anything]{may omit the entire assignment}.
 
 Modify 7.6(21/3):
 
@@ -407,7 +396,7 @@
   * An implementation {can omit raising}[need not always raise] an exception
     when a language-defined check fails. Instead, the operation that failed
     the check can simply yield an undefined result. The exception {is
-    required to be}[need be] raised by the implementation only if, in the
+    required to}[need] be raised by the implementation only if, in the
     absence of raising it, the value of this undefined result would have
     some effect on the external interactions of the program. In determining
     this, the implementation shall not presume that an undefined result has
@@ -424,6 +413,13 @@
     may[, but need not,] have discriminants{, though that is not required}, 
     and may be definite or indefinite.
 
+Modify 13.1(13/5):
+
+The specification of certain language-defined aspects {is not required
+to}[need not] be supported by all implementations; in such an implementation,
+the specification for such an aspect is illegal or raises an exception at
+run time.
+
 Modify 13.1(22/3):
 
   * An implementation {is not required to}[need not] support the
@@ -507,7 +503,7 @@
     packing. A component whose Size is greater than the word size may be
     allocated an integral number of words.
 
-Modify 13.3(29/2):
+Modify 13.3(31/2):
 
   * An implementation {is not required to}[need not] support an Alignment 
     clause for a signed integer type specifying an Alignment greater than 
@@ -516,7 +512,7 @@
     may be imposed for modular integer types, fixed point types, enumeration
     types, record types, and array types.
 
-Modify 13.3(30/2):
+Modify 13.3(32/2):
 
   * An implementation {is not required to}[need not] support a nonconfirming 
     Alignment clause {that can cause}[which could enable] the creation of an 
@@ -525,22 +521,22 @@
 
 [Replace "need not support", "could enable" - Editor.]
 
-Modify 13.3(30.1/2):
+Modify 13.3(32.1/2):
 
   * An implementation {is not required to}[need not] support an Alignment
     specified for a derived tagged type {that}[which] is not a multiple of
-    the Alignment of the parent type. An implementation need not support a 
-    nonconfirming Alignment specified for a derived untagged by-reference
-    type.
+    the Alignment of the parent type. An implementation {is not required
+    to}[need not] support a nonconfirming Alignment specified for a derived
+    untagged by-reference type.
 
-Modify 13.3(33.2/2):
+Modify 13.3(35.2/2):
 
   * An implementation {is not required to}[need not] support Alignments
     specified for objects of a by-reference type or for objects of types
     containing aliased subcomponents if the specified Alignment is not a 
     multiple of the Alignment of the subtype of the object.
 
-Modify 13.3(51.2/2):
+Modify 13.3(56.2/2):
 
   * An implementation {is not required to}[need not] support a Size clause for
     a signed integer type specifying a Size greater than that of the largest
@@ -549,12 +545,12 @@
     corresponding limitation may be imposed for modular integer types,
     fixed point types, enumeration types, record types, and array types.
 
-Modify 13.3(51.3/2):
+Modify 13.3(56.3/2):
 
   * A nonconfirming size clause for the first subtype of a derived
     untagged by-reference type {is not required to}[need not] be supported.
 
-Modify 13.3(65):
+Modify 13.3(72):
 
   * An implementation {is not required to}[need not] support specified 
     Component_Sizes that are less than the Size of the component subtype.
@@ -576,7 +572,7 @@
 
   * Otherwise, a default storage pool should be created at the point
     where the anonymous access type is elaborated; such a storage pool
-    [need not support]{can have no mechanism for the} deallocation of
+    [need not support]{may have no mechanism for the} deallocation of
     individual objects.
 
 Modify 13.12.1(7/2):
@@ -643,18 +639,8 @@
     {When}[If] the associated check is [too] complex, {it is optional to}[an
     implementation need not] propagate Data_Error as part of a procedure Read
     (or the Read attribute) {when}[if] the value read cannot be interpreted
-    is a value of the required subtype.]
-
-[Less radical alternative:
-    If the associated check is too complex, an implementation {does not have
-    to}[need not] propagate Data_Error as part of a procedure Read (or the
-    Read attribute) [if]{even though} the value read cannot be interpreted
     as a value of the required subtype.
 
-"does not have to" sounds rather close to a negative permission, as does most
-of the alternatives we tried. So the more substantial rewrite is
-preferred - Editor.]
-
 Modify B.1(41/4):
 
     For each supported convention L other than Intrinsic, an implementation
@@ -786,18 +772,18 @@
     instantiations of the generic package for the appropriate predefined 
     type{, though that is not required}.
 
-Modify G.3.1(156/2):
+Modify G.3.2(156/2):
 
     The nongeneric equivalent packages [may, but need not,]{can} be actual
     instantiations of the generic package for the appropriate predefined 
     type{, though that is not required}.
 
-Modify G.3.1(157/2): 
+Modify G.3.2(157/2): 
 
     Although many operations are defined in terms of operations from
-    numerics.generic_complex_types, they [need not]{can} be implemented by
-    [calling those operations provided that the]{other operations that have
-    the same} effect[ is the same].
+    {Numerics.Generic_Complex_Types}[numerics.generic_complex_types], they
+    [need not]{can} be implemented by [calling those operations provided that
+    the]{other operations that have the same} effect[ is the same].
 
 Modify H.7.1(14/5):
 
@@ -866,6 +852,1094 @@
 to somehow have both versions in any Corrigendum document, one for our use and
 one for the actual ISO Corrigendum). As such, we want to make any changes that
 do not clearly alter the meaning or harm the understandability of the text.
+
+
+
+!corrigendum 1.1.5(8)
+
+@drepl
+@xindent<The language rules define certain kinds of errors that  
+need not be detected either prior to or during run time,
+but if not detected, the range of possible effects shall be bounded.
+The errors of this category are called @i<bounded errors>. The possible 
+effects of a given bounded error are specified for each such error, 
+but in any case one possible effect of a bounded error is the raising
+of the exception Program_Error.>
+@dby
+@xindent<The language rules define certain kinds of errors that are not 
+expected to be detected either prior to or during run time,
+but if not detected, the range of possible effects shall be bounded.
+The errors of this category are called @i<bounded errors>. The possible 
+effects of a given bounded error are specified for each such error, 
+but in any case one possible effect of a bounded error is the raising
+of the exception Program_Error.>
+
+!corrigendum 1.1.5(10)
+
+@drepl
+@xindent<In addition to bounded errors, the language rules define certain kinds
+of errors as leading to @i<erroneous execution>. Like bounded errors, the
+implementation need not detect such errors 
+either prior to or during run time. Unlike bounded errors, there is no
+language-specified bound on the possible effect of erroneous execution;
+the effect is in general not predictable.>
+@dby
+@xindent<In addition to bounded errors, the language rules define certain kinds
+of errors as leading to @i<erroneous execution>. Like bounded errors, the
+implementation is not expected to detect such errors 
+either prior to or during run time. Unlike bounded errors, there is no
+language-specified bound on the possible effect of erroneous execution;
+the effect is in general not predictable.>
+
+
+!corrigendum 2.1(4/5)
+
+@drepl
+The coded representation for characters is implementation defined
+(it need not be a representation defined within ISO/IEC 10646:2017).
+A character whose relative code point in its plane is 16#FFFE# or 16#FFFF#
+is not allowed anywhere in the text of a program. 
+The only characters allowed outside of comments are those in categories
+@fa<other_format>, @fa<format_effector>, and @fa<graphic_character>.
+@dby
+The coded representation for characters is implementation defined
+(it can be a representation that is not defined within ISO/IEC 10646:2017).
+A character whose relative code point in its plane is 16#FFFE# or 16#FFFF#
+is not allowed anywhere in the text of a program. 
+The only characters allowed outside of comments are those in categories
+@fa<other_format>, @fa<format_effector>, and @fa<graphic_character>.
+
+
+!corrigendum 3.5.4(5)
+
+@drepl
+Each @fa<simple_expression> in a @fa<signed_integer_type_definition> is
+expected to be of any integer type; they need not be of the same
+types. The expression in a @fa<modular_type_definition> is likewise
+expected to be of any integer type.
+@dby
+Each @fa<simple_expression> in a @fa<signed_integer_type_definition> is 
+expected to be of any integer type; they can be of different
+integer types. The @fa<expression> in a @fa<modular_type_definition> is
+likewise expected to be of any integer type.
+
+!corrigendum 3.5.4(24)
+
+@drepl
+For the execution of a predefined operation of a signed integer type, the
+implementation need not raise Constraint_Error if the result is outside the
+base range of the type, so long as the correct result is produced.
+@dby
+For the execution of a predefined operation of a signed integer type, it
+is optional to raise Constraint_Error if the result is outside the base range
+of the type, so long as the correct result is produced.
+
+!corrigendum 3.5.4(25)
+
+@drepl
+An implementation may provide additional predefined signed integer types,
+declared in the visible part of Standard, whose first subtypes have names
+of the form Short_Integer, Long_Integer, Short_Short_Integer,
+Long_Long_Integer, etc. Different predefined integer types are allowed to
+have the same base range. However, the range of Integer should be no wider
+than that of Long_Integer. Similarly, the range of Short_Integer (if
+provided) should be no wider than Integer. Corresponding recommendations
+apply to any other predefined integer types. There need not be a named 
+integer type corresponding to each distinct base range supported by an
+implementation. The range of each first subtype should be the base range of
+its type.
+@dby
+An implementation may provide additional predefined signed integer types,
+declared in the visible part of Standard, whose first subtypes have names
+of the form Short_Integer, Long_Integer, Short_Short_Integer,
+Long_Long_Integer, etc. Different predefined integer types are allowed to
+have the same base range. However, the range of Integer should be no wider
+than that of Long_Integer. Similarly, the range of Short_Integer (if
+provided) should be no wider than Integer. Corresponding recommendations
+apply to any other predefined integer types. An implementation may support
+base ranges for which there is no corresponding named integer type. The
+range of each first subtype should be the base range of its type.
+
+!corrigendum 3.5.4(26)
+
+@drepl
+An implementation may provide @i<nonstandard integer types>, descendants of
+@i<root_integer> that are declared outside of the specification of package
+Standard, which need not have all the standard 
+characteristics of a type defined by an @fa<integer_type_definition>.
+For example, a nonstandard integer type
+might have an asymmetric base range or it might not be allowed as an array
+or loop index (a very long integer). Any type descended from a nonstandard
+integer type is also nonstandard. An implementation may place arbitrary
+restrictions on the use of such types; it is implementation defined whether
+operators that are predefined for "any integer type" are defined for a
+particular nonstandard integer type. In any case, such types are not permitted
+as @fa<explicit_generic_actual_parameter>s for formal scalar types @emdash
+see 12.5.2.
+@dby
+An implementation may provide @i<nonstandard integer types>, descendants of
+@i<root_integer> that are declared outside of the specification of package
+Standard, which may have different characteristics than a type defined by an
+@fa<integer_type_definition>. For example, a nonstandard integer type
+can have an asymmetric base range or it can be disallowed as an array or 
+loop index (a very long integer). Any type descended from a nonstandard
+integer type is also nonstandard. An implementation may place arbitrary
+restrictions on the use of such types; it is implementation defined whether
+operators that are predefined for "any integer type" are defined for a
+particular nonstandard integer type. In any case, such types are not permitted
+as @fa<explicit_generic_actual_parameter>s for formal scalar types @emdash
+see 12.5.2.
+
+
+!corrigendum 3.5.6(7/2)
+
+@drepl
+For the execution of a predefined operation of a real type, the implementation
+need not raise Constraint_Error if the result is outside the base range of the
+type, so long as the correct result is produced, or the Machine_Overflows 
+attribute of the type is False (see G.2).
+@dby
+For the execution of a predefined operation of a real type, it is optional to
+raise Constraint_Error if the result is outside the base range of the
+type, so long as the correct result is produced, or the Machine_Overflows 
+attribute of the type is False (see G.2.1).
+
+!corrigendum 3.5.6(8)
+
+@drepl
+An implementation may provide @i<nonstandard real types>, descendants of
+@i<root_real> that are declared outside of the specification of package
+Standard, which need not have all the standard characteristics of a type 
+defined by a @fa<real_type_definition>. For example, a nonstandard real type
+might have an asymmetric or unsigned base range, or its predefined operations
+might wrap around or "saturate" rather than overflow (modular or saturating 
+arithmetic), or it might not conform to the accuracy model (see G.2.1). Any type
+descended from a nonstandard real type is also nonstandard. An implementation
+may place arbitrary restrictions on the use of such types; it is 
+implementation defined whether operators that are predefined for "any real 
+type" are defined for a particular nonstandard real type. In any case, such 
+types are not permitted as @fa<explicit_generic_actual_parameter>s for formal
+scalar types @emdash see 12.5.2.
+@dby
+An implementation may provide @i<nonstandard real types>, descendants of
+@i<root_real> that are declared outside of the specification of package
+Standard, which may have different characteristics than a type 
+defined by a @fa<real_type_definition>. For example, a nonstandard real type
+can have an asymmetric or unsigned base range, or its predefined operations
+can wrap around or "saturate" rather than overflow (modular or saturating 
+arithmetic), or it can have a different accuracy model than is standard
+(see G.2.1). Any type
+descended from a nonstandard real type is also nonstandard. An implementation
+may place arbitrary restrictions on the use of such types; it is 
+implementation defined whether operators that are predefined for "any real 
+type" are defined for a particular nonstandard real type. In any case, such 
+types are not permitted as @fa<explicit_generic_actual_parameter>s for formal
+scalar types @emdash see 12.5.2.
+
+
+!corrigendum 3.5.7(5)
+
+@drepl
+Each @fa<simple_expression> of a @fa<real_range_specification> is expected to be of
+any real type; the types need not be the same.
+@dby
+Each @fa<simple_expression> of a @fa<real_range_specification> is expected to be of
+any real type; the types can be different.
+
+!corrigendum 3.5.7(16)
+
+@drepl
+An implementation is allowed to provide additional predefined floating
+point types, declared in the visible part of Standard, whose (unconstrained)
+first subtypes have names of the form Short_Float, Long_Float,
+Short_Short_Float, Long_Long_Float, etc. Different predefined floating point
+types are allowed to have the same base decimal precision. However, the
+precision of Float should be no greater than that of Long_Float. Similarly,
+the precision of Short_Float (if provided) should be no greater than Float.
+Corresponding recommendations apply to any other predefined floating point
+types. There need not be a named floating point type corresponding to each
+distinct base decimal precision supported by an implementation.
+@dby
+An implementation is allowed to provide additional predefined floating
+point types, declared in the visible part of Standard, whose (unconstrained)
+first subtypes have names of the form Short_Float, Long_Float,
+Short_Short_Float, Long_Long_Float, etc. Different predefined floating point
+types are allowed to have the same base decimal precision. However, the
+precision of Float should be no greater than that of Long_Float. Similarly,
+the precision of Short_Float (if provided) should be no greater than Float.
+Corresponding recommendations apply to any other predefined floating point
+types. An implementation may support base decimal precisions for which
+there is no corresponding named floating point type.
+
+
+!corrigendum 3.6(15)
+
+@drepl
+An @fa<unconstrained_array_definition> defines an array type with an
+unconstrained first subtype. Each @fa<index_subtype_definition> defines the
+corresponding index subtype to be the subtype denoted by the @fa<subtype_mark>.
+The compound delimiter <@> (called a @i<box>) of an @fa<index_subtype_definition>
+stands for an undefined range (different objects of the type need not
+have the same bounds).
+@dby
+An @fa<unconstrained_array_definition> defines an array type with an
+unconstrained first subtype. Each @fa<index_subtype_definition> defines the
+corresponding index subtype to be the subtype denoted by the @fa<subtype_mark>.
+The compound delimiter <@> (called a @i<box>) of an @fa<index_subtype_definition>
+stands for an undefined range (different objects of the type can have 
+different bounds).
+
+
+!corrigendum 3.9.3(6/4)
+
+@drepl
+@xbullet<Otherwise, the subprogram shall be overridden with a nonabstract
+subprogram or, in the case of a private extension inheriting a nonabstract
+function with a controlling result, have a full type that is a null extension;
+for a type declared in the visible part of a package, the overriding may be
+either in the visible or the private part. Such a subprogram is said to
+@i<require overriding>. However, if the type is a generic formal type, the
+subprogram need not be overridden for the formal type itself; a nonabstract
+version will necessarily be provided by the actual type.>
+@dby
+@xbullet<Otherwise, the subprogram shall be overridden with a nonabstract
+subprogram or, in the case of a private extension inheriting a nonabstract
+function with a controlling result, have a full type that is a null extension;
+for a type declared in the visible part of a package, the overriding may be
+either in the visible or the private part. Such a subprogram is said to
+@i<require overriding>. However, if the type is a generic formal type, the
+subprogram is allowed to be inherited as is, without being overridden for the
+formal type itself; a nonabstract version will necessarily be provided by the
+actual type.>
+
+
+!corrigendum 6.1.2(0)
+
+@dinsc
+See the conflict file for the changes.
+
+!corrigendum 6.3(4)
+
+@drepl
+In contrast to other bodies, a @fa<subprogram_body> need not be the completion
+of a previous declaration, in which case the body declares the subprogram. If
+the body is a completion, it shall be the completion of a @fa<subprogram_declaration> or
+@fa<generic_subprogram_declaration>. The profile of a @fa<subprogram_body> that 
+completes a declaration shall conform fully to that of the declaration.
+@dby
+In contrast to other bodies, a @fa<subprogram_body> is allowed to be defined 
+without it being the completion of a previous declaration,
+in which case the body declares the subprogram. If the body is a
+completion, it shall be the completion of a @fa<subprogram_declaration> or
+@fa<generic_subprogram_declaration>. The profile of a @fa<subprogram_body> that 
+completes a declaration shall conform fully to that of the declaration.
+
+
+!corrigendum 7.4(8/3)
+
+@drepl
+A deferred constant declaration for which the Import aspect is True need not
+appear in the visible part of a @fa<package_specification>, and has no full
+constant declaration.
+@dby
+A deferred constant declaration for which the Import aspect is True can
+appear anywhere that an @fa<object_declaration> is allowed, and has no full
+constant declaration.
+
+!corrigendum 7.6(19/3)
+
+@drepl
+If an object is assigned the value of that same object, the implementation need
+not do anything.
+@dby
+If an object is assigned the value of that same object, the implementation may
+omit the entire assignment.
+
+!corrigendum 7.6(21/3)
+
+@drepl
+@xbullet<The implementation need not
+create an anonymous object if the value being assigned is the result of
+evaluating a @fa<name> denoting an object (the source object) whose storage cannot
+overlap with the target. If the source object might overlap with the target
+object, then the implementation can avoid the need for an intermediary
+anonymous object by exercising one of the above permissions and perform the
+assignment one component at a time (for an overlapping array assignment), or
+not at all (for an assignment where the target and the source of the assignment
+are the same object).>
+@dby
+@xbullet<The implementation may avoid creating an anonymous object if the value 
+being assigned is the result of evaluating a @fa<name> denoting an object (the
+source object) whose storage cannot overlap with the target. If the source
+object can overlap with the target object, then the implementation can avoid
+the need for an intermediary anonymous object by exercising one of the above
+permissions and perform the assignment one component at a time (for an
+overlapping array assignment), or not at all (for an assignment where the
+target and the source of the assignment are the same object).>
+
+
+!corrigendum 9.5.3(22)
+
+@drepl
+An implementation may perform the sequence of steps of a protected action
+using any thread of control; it need not be
+that of the task that started the protected action. If an @fa<entry_body>
+completes without requeuing, then the corresponding calling task may be
+made ready without waiting for the entire protected action to complete.
+@dby
+An implementation may perform the sequence of steps of a protected action
+using any thread of control; it can be a thread other than
+that of the task that started the protected action. If an @fa<entry_body>
+completes without requeuing, then the corresponding calling task may be
+made ready without waiting for the entire protected action to complete.
+
+!corrigendum 9.5.3(23/4)
+
+@drepl
+When the entry of a protected object is checked to see whether it is
+open, the implementation need not reevaluate
+the @fa<condition> of the corresponding @fa<entry_barrier> if no variable or 
+attribute referenced by the @fa<condition> (directly or indirectly) has been
+altered by the execution (or cancellation) of a call to an exclusive
+protected operation of the object since the @fa<condition> was last evaluated.
+@dby
+When the entry of a protected object is checked to see whether it is
+open, the implementation can bypass reevaluating
+the @fa<condition> of the corresponding @fa<entry_barrier> if no variable or 
+attribute referenced by the @fa<condition> (directly or indirectly) has been
+altered by the execution (or cancellation) of a call to an exclusive
+protected operation of the object since the @fa<condition> was last evaluated.
+
+!corrigendum 9.5.3(25)
+
+@drepl
+When an attempt is made to cancel an entry call, the implementation need not
+make the attempt using the thread of control 
+of the task (or interrupt) that initiated the cancellation; in
+particular, it may use the thread of control of the caller itself to
+attempt the cancellation, even if this might allow the entry call
+to be selected in the interim.
+@dby
+When an attempt is made to cancel an entry call, the implementation can 
+use a thread of control other than 
+that of the task (or interrupt) that initiated the cancellation; in
+particular, it may use the thread of control of the caller itself to
+attempt the cancellation, even if this can allow the entry call
+to be selected in the interim.
+
+!corrigendum 9.6(31)
+
+@drepl
+The time base for @fa<delay_relative_statement>s should be monotonic; it
+need not be the same time base as used for Calendar.Clock.
+@dby
+The time base for @fa<delay_relative_statement>s should be monotonic; it
+can be different than the time base as used for Calendar.Clock.
+
+!corrigendum 9.8(3)
+
+@drepl
+Each @i<task_>@fa<name> is expected to be of any task type; they need not all be of
+the same task type.
+@dby
+Each @i<task_>@fa<name> is expected to be of any task type; each can be of a
+different task type.
+
+!corrigendum 9.10.1(0)
+
+@dinsc
+See the conflict file for the changes.
+
+
+!corrigendum 10.1.3(11)
+
+@drepl
+In contrast, a @fa<subprogram_body_stub> need not be the completion of
+a previous declaration, in which case the
+@fa<_stub> declares the subprogram. If the @fa<_stub> is a completion, it shall be
+the completion of a @fa<subprogram_declaration> or
+@fa<generic_subprogram_declaration>. The profile of a @fa<subprogram_body_stub> that
+completes a declaration shall conform fully to that of the declaration.
+@dby
+In contrast, a @fa<subprogram_body_stub> can be defined without it being the
+completion of a previous declaration, in which case the
+@fa<_stub> declares the subprogram. If the @fa<_stub> is a completion, it shall be
+the completion of a @fa<subprogram_declaration> or
+@fa<generic_subprogram_declaration>. The profile of a @fa<subprogram_body_stub> that
+completes a declaration shall conform fully to that of the declaration.
+
+!corrigendum 10.2.1(11.2/3)
+
+@drepl
+@xbullet<The partial view
+of a private type or private extension, a protected type without
+@fa<entry_declaration>s, a generic formal private type, or a generic formal
+derived type, has preelaborable
+initialization if and only if the @fa<pragma> Preelaborable_Initialization has
+been applied to them. A protected type with @fa<entry_declaration>s
+or a task type never has preelaborable initialization.>
+@dby
+@xbullet<The partial view
+of a private type or private extension, a protected type without
+@fa<entry_declaration>s, a generic formal private type, or a generic formal
+derived type, has preelaborable
+initialization if and only if the Preelaborable_Initialization aspect has
+been specified True for them. A protected type with @fa<entry_declaration>s
+or a task type never has preelaborable initialization. The 
+Preelaborable_Initialization aspect of a partial
+view of a type may be specified as False, even if the full view of the
+type has preelaborable initialization. Similarly, a generic formal
+type may be specified with Preelaborable_Initialization False, even
+if the actual type in an instance has preelaborable initialization.>
+
+
+!corrigendum 11.4.2(27/3)
+
+@drepl
+An implementation need not allow the specification of an
+assertion expression if the evaluation of the expression has a side effect
+such that an immediate reevaluation of the expression could produce
+a different value. Similarly, an implementation need not allow
+the specification of an assertion expression that is checked as
+part of a call on or return from a callable entity @i<C>, if the evaluation of
+the expression has a side effect such that the evaluation of some other
+assertion expression associated with the same call of (or return from) @i<C>
+could produce a different value than it would if
+the first expression had not been evaluated.
+@dby
+An implementation may disallow the specification of an
+assertion expression if the evaluation of the expression has a side effect
+such that an immediate reevaluation of the expression can produce
+a different value. Similarly, an implementation may
+disallow the specification of an assertion expression that is checked as
+part of a call on or return from a callable entity @i<C>, if the evaluation of
+the expression has a side effect such that the evaluation of some other
+assertion expression associated with the same call of (or return from) @i<C>
+can produce a different value than in the case when
+the first expression had not been evaluated.
+
+!corrigendum 11.6(5)
+
+@drepl
+@xbullet<An implementation need not always raise an exception
+  when a language-defined check fails. Instead, the operation that failed
+  the check can simply yield an @i<undefined result>. The exception
+  need be raised by the implementation only if, in the
+  absence of raising it, the value of this undefined result would have
+  some effect on the external interactions of the program. In determining
+  this, the implementation shall not presume that an undefined result has
+  a value that belongs to its subtype, nor even to the base range of its
+  type, if scalar. Having removed the raise of the exception, the canonical
+  semantics will in general allow the implementation to omit the code
+  for the check, and some or all of the operation itself.>
+@dby
+@xbullet<An implementation can omit raising an exception
+  when a language-defined check fails. Instead, the operation that failed
+  the check can simply yield an @i<undefined result>. The exception is
+  required to be raised by the implementation only if, in the
+  absence of raising it, the value of this undefined result would have
+  some effect on the external interactions of the program. In determining
+  this, the implementation shall not presume that an undefined result has
+  a value that belongs to its subtype, nor even to the base range of its
+  type, if scalar. Having removed the raise of the exception, the canonical
+  semantics will in general allow the implementation to omit the code
+  for the check, and some or all of the operation itself.>
+
+
+!corrigendum 12.5.1(15)
+
+@drepl
+For a generic formal type with an @fa<unknown_discriminant_part>, the actual
+may, but need not, have discriminants, and may be definite or indefinite.
+@dby
+For a generic formal type with an @fa<unknown_discriminant_part>, the actual
+may have discriminants, though that is not required, 
+and may be definite or indefinite.
+
+
+!corrigendum 13.1(13/3)
+
+@drepl
+If a specification of a representation or operational aspect is not supported
+by the implementation, it is illegal or raises an exception at run time.
+@dby
+The specification of certain language-defined aspects is not required to be
+supported by all implementations; in such an implementation, the specification
+for such an aspect is illegal or raises an exception at run time.
+
+
+!corrigendum 13.1(22/3)
+
+@drepl
+@xbullet<An implementation need not support the
+specification for a representation aspect that contains nonstatic
+expressions, unless each nonstatic expression is a @fa<name> that
+statically denotes a constant declared before the entity.>
+@dby
+@xbullet<An implementation is not required to support the
+specification for a representation aspect that contains nonstatic
+expressions, unless each nonstatic expression is a @fa<name> that
+statically denotes a constant declared before the entity.>
+
+!corrigendum 13.1(23/5)
+
+@drepl
+@xbullet<An implementation need not support a specification
+for the Object_Size or Size for a given composite subtype, nor the size or
+storage place for an object (including a component) of a given
+composite subtype, unless the constraints on the subtype and its
+composite subcomponents (if any) are all static constraints.>
+@dby
+@xbullet<An implementation is not required to support a specification
+for the Object_Size or Size for a given composite subtype, nor the size or
+storage place for an object (including a component) of a given
+composite subtype, unless the constraints on the subtype and its
+composite subcomponents (if any) are all static constraints.>
+
+!corrigendum 13.1(24/3)
+
+@drepl
+@xbullet<An implementation need not support specifying a
+nonconfirming representation aspect value if it could cause an
+aliased object or an object of a by-reference type to be allocated at
+a nonaddressable location or, when the alignment attribute of the subtype
+of such an object is nonzero, at an address that is not an integral 
+multiple of that alignment.>
+@dby
+@xbullet<An implementation is not required to support specifying a
+nonconfirming representation aspect value if it can cause an
+aliased object or an object of a by-reference type to be allocated at
+a nonaddressable location or, when the alignment attribute of the subtype
+of such an object is nonzero, at an address that is not an integral 
+multiple of that alignment.>
+
+!corrigendum 13.1(25/3)
+
+@drepl
+@xbullet<An implementation need not support specifying a
+nonconfirming representation aspect value if it could cause an
+aliased object of an elementary type to have a size other than that
+which would have been chosen by default.>
+@dby
+@xbullet<An implementation is not required to support specifying a
+nonconfirming representation aspect value if it can cause an
+aliased object of an elementary type to have a size other than that
+which would have been chosen by default.>
+
+!corrigendum 13.1(26/3)
+
+@drepl
+@xbullet<An implementation need not support specifying a
+nonconfirming representation aspect value if it can cause an
+aliased object of a composite type, or an object whose type is
+by-reference, to have a size smaller than that which would have been
+chosen by default.>
+@dby
+@xbullet<An implementation is not required to support specifying a
+nonconfirming representation aspect value if it can cause an
+aliased object of a composite type, or an object whose type is
+by-reference, to have a size smaller than that which would have been
+chosen by default.>
+
+!corrigendum 13.1(27/3)
+
+@drepl
+@xbullet<An implementation need not support specifying a 
+nonconfirming subtype-specific representation aspect value for an
+indefinite or abstract subtype.>
+@dby
+@xbullet<An implementation is not required to support specifying a 
+nonconfirming subtype-specific representation aspect value for an
+indefinite or abstract subtype.>
+
+!corrigendum 13.1(28/3)
+
+@drepl
+For purposes of these rules, the determination of whether specifying a
+representation aspect value for a type @i<could cause> an object to have
+some property is based solely on the properties of the type itself, not on
+any available information about how the type is used. In particular, it
+presumes that minimally aligned objects of this type can be 
+declared at some point.
+@dby
+For purposes of these rules, the determination of whether specifying a
+representation aspect value for a type @i<can cause> an object to have
+some property is based solely on the properties of the type itself, not on
+any available information about how the type is used. In particular, it
+presumes that minimally aligned objects of this type can be 
+declared at some point.
+
+!corrigendum 13.2(8/4)
+
+@drepl
+@xbullet<For a packed record type, the components should be packed as tightly
+as possible subject to the above alignment requirements, the Sizes of
+the component subtypes, and any @fa<record_representation_clause> that
+applies to the type; the implementation may, but need not,
+reorder components or cross aligned word boundaries to improve the 
+packing. A component whose Size is greater than the word size may be
+allocated an integral number of words.>
+@dby
+@xbullet<For a packed record type, the components should be packed as tightly
+as possible subject to the above alignment requirements, the Sizes of
+the component subtypes, and any @fa<record_representation_clause> that
+applies to the type; the implementation is allowed
+to reorder components or cross aligned word boundaries to improve the 
+packing. A component whose Size is greater than the word size may be
+allocated an integral number of words.>
+
+!corrigendum 13.3(31/2)
+
+@drepl
+@xbullet<An implementation need not support an Alignment 
+clause for a signed integer type specifying an Alignment greater than 
+the largest Alignment value that is ever chosen by default by the
+implementation for any signed integer type. A corresponding limitation
+may be imposed for modular integer types, fixed point types, enumeration
+types, record types, and array types.>
+@dby
+@xbullet<An implementation is not required to support an Alignment 
+clause for a signed integer type specifying an Alignment greater than 
+the largest Alignment value that is ever chosen by default by the
+implementation for any signed integer type. A corresponding limitation
+may be imposed for modular integer types, fixed point types, enumeration
+types, record types, and array types.>
+
+!corrigendum 13.3(32/2)
+
+@drepl
+@xbullet<An implementation need not support a nonconfirming 
+Alignment clause which could enable the creation of an 
+object of an elementary type which cannot be easily loaded and
+stored by available machine instructions.>
+@dby
+@xbullet<An implementation is not required to support a nonconfirming 
+Alignment clause that can cause the creation of an 
+object of an elementary type that cannot be easily loaded and
+stored by available machine instructions.>
+
+!corrigendum 13.3(32.1/2)
+
+@drepl
+@xbullet<An implementation need not support an Alignment
+specified for a derived tagged type which is not a multiple of
+the Alignment of the parent type. An implementation need not to support
+a nonconfirming Alignment specified for a derived untagged by-reference type.>
+@dby
+@xbullet<An implementation is not required to support an Alignment
+specified for a derived tagged type that is not a multiple of
+the Alignment of the parent type. An implementation is not required to support
+a nonconfirming Alignment specified for a derived untagged by-reference type.>
+
+!corrigendum 13.3(35.2/2)
+
+@drepl
+@xbullet<An implementation need not support Alignments
+specified for objects of a by-reference type or for objects of types
+containing aliased subcomponents if the specified Alignment is not a 
+multiple of the Alignment of the subtype of the object.>
+@dby
+@xbullet<An implementation is not required to support Alignments
+specified for objects of a by-reference type or for objects of types
+containing aliased subcomponents if the specified Alignment is not a 
+multiple of the Alignment of the subtype of the object.>
+
+!corrigendum 13.3(56.2/2)
+
+@drepl
+@xinbull<An implementation need not support a Size clause for
+a signed integer type specifying a Size greater than that of the largest
+signed integer type supported by the implementation in the absence
+of a size clause (that is, when the size is chosen by default). A
+corresponding limitation may be imposed for modular integer types,
+fixed point types, enumeration types, record types, and array types.>
+@dby
+@xinbull<An implementation is not required to support a Size clause for
+a signed integer type specifying a Size greater than that of the largest
+signed integer type supported by the implementation in the absence
+of a size clause (that is, when the size is chosen by default). A
+corresponding limitation may be imposed for modular integer types,
+fixed point types, enumeration types, record types, and array types.>
+
+!corrigendum 13.3(56.3/2)
+
+@drepl
+@xinbull<A nonconfirming size clause for the first subtype of a derived
+untagged by-reference type need not be supported.>
+@dby
+@xinbull<A nonconfirming size clause for the first subtype of a derived
+untagged by-reference type is not required to be supported.>
+
+!corrigendum 13.3(72)
+
+@drepl
+@xbullet<An implementation need not support specified 
+Component_Sizes that are less than the Size of the component subtype.>
+@dby
+@xbullet<An implementation is not required to support specified 
+Component_Sizes that are less than the Size of the component subtype.>
+
+!corrigendum 13.4(10)
+
+@drepl
+@xbullet<An implementation should support at least the internal codes in the
+range System.Min_Int .. System.Max_Int. An implementation need not
+support @fa<enumeration_representation_clause>s for boolean types.>
+@dby
+@xbullet<An implementation should support at least the internal codes in the
+range System.Min_Int .. System.Max_Int. An implementation is not required
+to support @fa<enumeration_representation_clause>s for boolean types.>
+
+!corrigendum 13.5.1(22)
+
+@drepl
+@xbullet<An implementation need not support a @fa<component_clause>
+for a component of an extension part if the storage place is not after the
+storage places of all components of the parent type, whether or not those
+storage places had been specified.>
+@dby
+@xbullet<An implementation is not required to support a @fa<component_clause>
+for a component of an extension part if the storage place is not after the
+storage places of all components of the parent type, whether or not those
+storage places had been specified.>
+
+!corrigendum 13.11(25.4/2)
+
+@drepl
+@xbullet<Otherwise, a default storage pool should be created at the point
+where the anonymous access type is elaborated; such a storage pool
+need not support deallocation of individual objects.>
+@dby
+@xbullet<Otherwise, a default storage pool should be created at the point
+where the anonymous access type is elaborated; such a storage pool
+may have no mechanism for the deallocation of individual objects.>
+
+!corrigendum 13.12.1(7/2)
+
+@drepl
+The @fa<restriction_parameter_argument> of a No_Dependence restriction shall be
+a @fa<name>; the @fa<name> shall have the form of a full expanded name of a library
+unit, but need not denote a unit present in the environment.
+@dby
+The @fa<restriction_parameter_argument> of a No_Dependence restriction shall be
+a @fa<name>; the @fa<name> shall have the form of a full expanded name of a
+library unit, but can be a name that has no corresponding unit currently present
+in the environment.
+
+!corrigendum 13.13.1(36/5)
+
+@drepl
+If Stream_Element'Size is not a multiple of System.Storage_Unit, then the
+components of Stream_Element_Array need not be aliased.
+@dby
+If Stream_Element'Size is not a multiple of System.Storage_Unit, then the
+components of Stream_Element_Array will not be aliased.
+
+
+!corrigendum A.4.12(0)
+
+@dinsc
+See the conflict file for the changes.
+
+!corrigendum A.5.1(48)
+
+@drepl
+The nongeneric equivalent packages may, but need not, be actual
+instantiations of the generic package for the appropriate predefined type.
+@dby
+The nongeneric equivalent packages can be actual instantiations of the generic
+package for the appropriate predefined type, though that is not required.
+
+!corrigendum A.10(8)
+
+@drepl
+The actual nature of terminators is not defined by the language and hence
+depends on the implementation. Although terminators are recognized or
+generated by certain of the procedures that follow, they are not
+necessarily implemented as characters or as sequences of characters.
+Whether they are characters (and if so which ones) in any particular
+implementation need not concern a user who neither 
+explicitly outputs nor explicitly inputs control characters. The effect of
+input (Get) or output (Put) of control characters (other than horizontal
+tabulation) is not specified by the language.
+@dby
+The actual nature of terminators is not defined by the language and hence
+depends on the implementation. Although terminators are recognized or
+generated by certain of the procedures that follow, they are not
+necessarily implemented as characters or as sequences of characters.
+Whether they are characters (and if so which ones) in any particular
+implementation is not of concern to a user who neither 
+explicitly outputs nor explicitly inputs control characters. The effect of
+input (Get) or output (Put) of control characters (other than horizontal
+tabulation) is not specified by the language.
+
+!corrigendum A.10.8(23)
+
+@drepl
+The nongeneric equivalent packages may, but need not, be actual
+instantiations of the generic package for the appropriate predefined type.
+@dby
+The nongeneric equivalent packages can be actual instantiations of the generic
+package for the appropriate predefined type, though that is not required.
+
+!corrigendum A.10.9(36)
+
+@drepl
+The implementation of Put need not produce an output value with
+greater accuracy than is supported for the base subtype.
+The additional accuracy, if any, of the value produced by Put when the 
+number of requested digits in the integer and fractional parts exceeds the
+required accuracy is implementation defined.
+@dby
+The implementation of Put may produce an output value with
+no greater accuracy than that which is supported for the base subtype.
+The additional accuracy, if any, of the value produced by Put when the 
+number of requested digits in the integer and fractional parts exceeds the
+required accuracy is implementation defined.
+
+!corrigendum A.10.9(37)
+
+@drepl
+The nongeneric equivalent packages may, but need not, be actual
+instantiations of the generic package for the appropriate predefined type.
+@dby
+The nongeneric equivalent packages can be actual instantiations of the generic
+package for the appropriate predefined type, though that is not required.
+
+!corrigendum A.13(16)
+
+@drepl
+If the associated check is too complex, an implementation need not propagate
+Data_Error as part of a procedure Read (or the Read attribute) if the value
+read cannot be interpreted as a value of the required subtype.
+@dby
+When the associated check is complex, it is optional to propagate Data_Error
+as part of a procedure Read (or the Read attribute) when the value read cannot
+be interpreted as a value of the required subtype.
+
+
+!corrigendum B.1(41/4)
+
+@drepl
+For each supported convention @i<L> other than Intrinsic, an implementation
+should support specifying the Import and Export aspects for objects of
+@i<L>-compatible types and for subprograms, and the Convention aspect for
+@i<L>-eligible types and for subprograms, presuming the other language has
+corresponding features. Specifying the Convention aspect need not be supported
+for scalar types, other than enumeration types whose internal codes fall within
+the range 0 .. 2**15@endash1. 
+@dby
+For each supported convention @i<L> other than Intrinsic, an implementation
+should support specifying the Import and Export aspects for objects of
+@i<L>-compatible types and for subprograms, and the Convention aspect for
+@i<L>-eligible types and for subprograms, presuming the other language has
+corresponding features. Specifying the Convention aspect should be supported
+for enumeration types whose internal codes fall within the range
+0 .. 2**15@endash1, but no recommendation is made for other scalar types.
+
+!corrigendum B.3(62.1/3)
+
+@drepl
+An implementation need not support specifying the
+Convention aspect with @i<convention_>@fa<identifier> C in the following cases:
+@dby
+An implementation is not required to support specifying the
+Convention aspect with @i<convention_>@fa<identifier> C in the following cases:
+
+
+!corrigendum C.3.2(24/5)
+
+@drepl
+The implementation shall document, when the Ceiling_Locking policy (see D.3) 
+is in effect, the default ceiling priority 
+assigned to a protected object that contains a protected procedure that specifies 
+either the Attach_Handler or Interrupt_Handler aspects, but does not specify the 
+Interrupt_Priority aspect. This default need not be the same for all interrupts.
+@dby
+The implementation shall document, when the Ceiling_Locking policy (see D.3) 
+is in effect, the default ceiling priority 
+assigned to a protected object that contains a protected procedure that specifies 
+either the Attach_Handler or Interrupt_Handler aspects, but does not specify the 
+Interrupt_Priority aspect. This default can be different for different
+interrupts.
+
+
+!corrigendum D.2.2(17/2)
+
+@drepl
+Implementations are allowed to define other task dispatching policies,
+but need not support more than one task dispatching policy per partition.
+@dby
+Implementations are allowed to define other task dispatching policies,
+but are not required to support specifying more than one
+task dispatching policy per partition.
+
+!corrigendum D.2.2(18/2)
+
+@drepl
+An implementation need not support @fa<pragma>
+Priority_Specific_Dispatching if it is infeasible to support it in the
+target environment.
+@dby
+An implementation is not required to support @fa<pragma>
+Priority_Specific_Dispatching if it is infeasible to support it in the
+target environment.
+
+!corrigendum D.3(15/2)
+
+@drepl
+Implementations are allowed to define other locking policies, but 
+need not support more than one locking policy per partition.
+@dby
+Implementations are allowed to define other locking policies, but are
+not required to support specifying more than one locking policy per partition.
+
+!corrigendum D.4(15/2)
+
+@drepl
+Implementations are allowed to define other queuing policies, but need not
+support more than one queuing policy per partition.
+@dby
+Implementations are allowed to define other queuing policies, but are
+not required to support specifying more than one queuing policy per partition.
+
+!corrigendum D.4.1(0)
+
+@dinsc
+See the conflict file for the changes.
+
+!corrigendum D.8(46):
+
+@drepl
+Implementations targeted to machines with word size smaller than 32 bits need
+not support the full range and granularity of the Time and Time_Span types.
+@dby
+Implementations targeted to machines with word size smaller than 32 bits
+may omit support for the full range and granularity of the Time and Time_Span
+types.
+
+!corrigendum D.11(10)
+
+@drepl
+An implementation need not support Asynchronous_Task_Control if it is
+infeasible to support it in the target environment.
+@dby
+An implementation may omit support for Asynchronous_Task_Control if it is
+infeasible to support it in the target environment.
+
+!corrigendum D.14(28/2)
+
+@drepl
+Implementations targeted to machines with word size smaller than 32 bits
+need not support the full range and granularity of the CPU_Time type.
+@dby
+Implementations targeted to machines with word size smaller than 32 bits
+may omit support for the full range and granularity of the CPU_Time type.
+
+
+!corrigendum E.1(13)
+
+@drepl
+In an implementation, the partitions of a distributed program need not 
+be loaded and elaborated all at the same time; they may be loaded and 
+elaborated one at a time over an extended period of time. An implementation
+may provide facilities to abort and reload a partition during the execution
+of a distributed program.
+@dby
+In an implementation, the partitions of a distributed program may be loaded
+and elaborated at different times; they may be loaded and elaborated one at
+a time over an extended period of time. An implementation may provide
+facilities to abort and reload a partition during the execution of a
+distributed program.
+
+!corrigendum E.2.3(20/5)
+
+@drepl
+An implementation need not support the 
+Remote_Call_Interface aspect nor the All_Calls_Remote aspect.
+Explicit message-based communication between active partitions can be
+supported as an alternative to RPC.
+@dby
+An implementation may omit support for the 
+Remote_Call_Interface aspect or the All_Calls_Remote aspect.
+Explicit message-based communication between active partitions can be
+supported as an alternative to RPC.
+
+!corrigendum E.5(27)
+
+@drepl
+A body for the package System.RPC need not be 
+supplied by the implementation.
+@dby
+A body for the package System.RPC is not required to be 
+supplied by the implementation.
+
+
+!corrigendum G.1.1(54)
+
+@drepl
+The nongeneric equivalent packages may, but need not, be actual
+instantiations of the generic package for the appropriate predefined type.
+@dby
+The nongeneric equivalent packages can be actual instantiations of the
+generic package for the appropriate predefined type, though that is not required.
+
+!corrigendum G.1.2(46)
+
+@drepl
+The nongeneric equivalent packages may, but need not, be actual
+instantiations of the generic package with the appropriate predefined
+nongeneric equivalent of Numerics.Generic_Complex_Types; if they are, then
+the latter shall have been obtained by actual instantiation of
+Numerics.Generic_Complex_Types.
+@dby
+The nongeneric equivalent packages can be actual instantiations of the generic
+package with the appropriate predefined nongeneric equivalent of
+Numerics.Generic_Complex_Types, though that is not required; if they are,
+then the latter shall have been obtained by actual instantiation of
+Numerics.Generic_Complex_Types.
+
+!corrigendum G.2(3)
+
+@drepl
+The two modes need not actually be different.
+@dby
+The two modes can be one and the same.
+
+!corrigendum G.3.1(87/2)
+
+@drepl
+The nongeneric equivalent packages may, but need not, be actual
+instantiations of the generic package for the appropriate predefined type.
+@dby
+The nongeneric equivalent packages can be actual instantiations of the
+generic package for the appropriate predefined type, though that is not required.
+
+!corrigendum G.3.2(156/2)
+
+@drepl
+The nongeneric equivalent packages may, but need not, be actual
+instantiations of the generic package for the appropriate predefined type.
+@dby
+The nongeneric equivalent packages can be actual instantiations of the
+generic package for the appropriate predefined type, though that is not required.
+
+!corrigendum G.3.2(157/2)
+
+@drepl
+Although many operations are defined in terms of operations from
+numerics.generic_complex_types, they need not be implemented by
+calling those operations provided that the effect is the same.
+@dby
+Although many operations are defined in terms of operations from
+Numerics.Generic_Complex_Types, they can be implemented by
+other operations that have the same effect.
+
+
+!corrigendum H.7.1(0)
+
+@dinsc
+See the conflict file for the changes.
 
 !ASIS
 

Questions? Ask the ACAA Technical Agent