Version 1.6 of ai12s/ai12-0444-1.txt
!standard 1.1.5(8) 22-05-05 AI12-0444-1/03
!standard 1.1.5(10)
!standard 2.1(4/5)
!standard 3.5.4(5)
!standard 3.5.4(24)
!standard 3.5.4(25)
!standard 3.5.4(26)
!standard 3.5.6(7/5)
!standard 3.5.6(8/5)
!standard 3.5.7(5)
!standard 3.5.7(16)
!standard 3.6(15)
!standard 3.9.3(6/4)
!standard 6.1.2(41/5)
!standard 6.3(4)
!standard 7.4(8/3)
!standard 7.6(19/3)
!standard 7.6(21/3)
!standard 9.5.3(22)
!standard 9.5.3(23/4)
!standard 9.5.3(25)
!standard 9.6(31)
!standard 9.8(3)
!standard 9.10.1(25/5)
!standard 10.1.3(11)
!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)
!standard 13.1(25/3)
!standard 13.1(26/3)
!standard 13.1(27/3)
!standard 13.1(28/3)
!standard 13.2(8/4)
!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)
!standard 13.12.1(7/2)
!standard 13.13.1(36/5)
!standard A.4.12(1/5)
!standard A.5.1(48)
!standard A.10(8)
!standard A.10.8(23)
!standard A.10.9(36)
!standard A.10.9(37)
!standard A.13(16)
!standard B.1(41/4)
!standard B.3(62.1/3)
!standard C.3.2(24/5)
!standard C.7.2(28)
!standard D.2.2(17/2)
!standard D.2.2(18/2)
!standard D.3(15/2)
!standard D.4(15/2)
!standard D.4.1(8/5)
!standard D.11(10)
!standard D.14(28/2)
!standard E.1(13)
!standard E.2.3(20/5)
!standard E.5(27)
!standard G.1.1(54)
!standard G.1.2(46)
!standard G.2(3)
!standard G.3.1(87/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
!status WG9 Approved 22-06-22
!status ARG Approved 14-0-0 22-05-05
!status work item 22-04-27
!status received 22-02-18
!priority Critical
!difficulty Medium
!subject Rewordings to remove "need not"
!summary
Several paragraphs needed to be reworded to avoid using "need not".
!question
ISO comment #20 says:
Verbal forms used to express provisions in the text do not always comply
with the rules specified in the ISO/IEC Directives, Part 2. Do not use
verbal forms ("could", "might", "need") that are not defined in the
ISO/IEC Directives, Part 2.
Should we fix any uses of "need not"? (Yes.)
!recommendation
Reword all wording including "need not", preferably into a positive statement.
Non-normative material like notes and examples including "need not" are
handled in AI12-0442-1; a single case is found in AI12-0438-1 as the paragraph
also includes "must"; the rest are found here.
!wording
Modify 1.1.5(8):
The language rules define certain kinds of errors that {are not
expected to}[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 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.
Modify 1.1.5(10):
In addition to bounded errors, the language rules define certain kinds
of errors as leading to erroneous execution. Like bounded errors, the
implementation {is not expected to}[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.
Modify 2.1(4/5):
The coded representation for characters is implementation defined (it
{can}[need not] 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
other_format, format_effector, and graphic_character.
Modify 3.5.4(5):
Each simple_expression in a signed_integer_type_definition is expected to
be of any integer type; they [need not be of the same]{can be of different
integer} type{s}. The expression in a modular_type_definition is likewise
expected to be of any integer type.
Modify 3.5.4(24):
For the execution of a predefined operation of a signed integer type, {it
is optional to}[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.
["Outside" was dubious; we now define it in 3.2(8) {see AI12-0445-1} in
part to make this sensible - Editor.]
Modify 3.5.4(25):
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]{An implementation may support}
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.
Modify 3.5.4(26):
An implementation may provide nonstandard integer types, descendants of
root_integer that are declared outside of the specification of package
Standard, which {may have different}[need not have all the standard]
characteristics {than}[of] a type defined by an integer_type_definition.
For example, a nonstandard integer type
{can}[might] have an asymmetric base range or it {can be disallowed}[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 explicit_generic_actual_parameters for formal scalar types - see 12.5.2.
["Could" would be better, especially for the second case, but that also a word
that's not allowed. Negative permissions are not allowed at all, there is no
negative form of "may". Thus the rewording for "need not" and "might not".
- Editor.]
Modify 3.5.6(7/5):
For the execution of a predefined operation of a real type, {it is
optional to}[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.1).
["Outside" was dubious; we now define it in 3.2(8) {see AI12-0445-1} in
part to make this sensible - Editor.]
Modify 3.5.6(8/5):
An implementation may provide nonstandard real types, descendants of
root_real that are declared outside of the specification of package Standard,
which {may have different}[need not have all the standard]
characteristics {than}[of] a type defined by a
real_type_definition. For example, a nonstandard real type {can}[might] have an
asymmetric or unsigned base range, or its predefined operations {can}[might]
wrap around or "saturate" rather than overflow (modular or saturating arithmetic),
or it {can have a different}[might not conform to the] 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
explicit_generic_actual_parameters for formal scalar types - see 12.5.2.
[See 3.5.4(26) for comments - Editor.]
Modify 3.5.7(5):
Each simple_expression of a real_range_specification is expected to be of
any real type; the types {can} [need not] be [the same]{different}.
Modify 3.5.7(16):
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]{An implementation may support} base decimal precision{s for which
there is no corresponding named floating point type} [supported by an
implementation].
Modify 3.6(15):
An unconstrained_array_definition defines an array type with an
unconstrained first subtype. Each index_subtype_definition defines the
corresponding index subtype to be the subtype denoted by the subtype_mark.
The compound delimiter <> (called a box) of an index_subtype_definition
stands for an undefined range (different objects of the type [need
not]{can} have [the same] {different} bounds).
Modify 3.9.3(6/4):
* 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 require overriding. However, if the
type is a generic formal type, the subprogram {is allowed to be inherited
as is, without being} [need not be] overridden for the formal type itself;
a nonabstract version will necessarily be provided by the actual type.
Modify 6.1.2(41/5):
An implementation [need not require that all]{can allow some} references
to a constant object [be]{which are not} accounted for by the Global or
Global'Class aspect when it is considered a variable in the above rules{,}
if the implementation can determine that the object is in fact immutable.
Modify 6.3(4):
In contrast to other bodies, a subprogram_body {is allowed to be defined
without it being} [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 subprogram_declaration or
generic_subprogram_declaration. The profile of a subprogram_body that
completes a declaration shall conform fully to that of the declaration.
Modify 7.4(8/3):
A deferred constant declaration for which the Import aspect is True [need
not]{can} appear [in the visible part of a package_specification]{anywhere
that an object_declaration is allowed}, and has no full constant
declaration.
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 entire assignment}.
Modify 7.6(21/3):
* The implementation [need not create]{may avoid creating} an anonymous
object if the value being assigned is the result of evaluating a name
denoting an object (the source object) whose storage cannot overlap with
the target. If the source object [might]{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).
["need not", bonus "might" - Editor.]
Modify 9.5.3(22):
An implementation may perform the sequence of steps of a protected action
using any thread of control; it [need not be]{can be a thread other than}
that of the task that started the protected action. If an entry_body
completes without requeuing, then the corresponding calling task may be
made ready without waiting for the entire protected action to complete.
Modify 9.5.3(23/4):
When the entry of a protected object is checked to see whether it is
open, the implementation [need not reevaluate]{can bypass reevaluating}
the condition of the corresponding entry_barrier if no variable or
attribute referenced by the 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 condition was last evaluated.
Modify 9.5.3(25):
When an attempt is made to cancel an entry call, the implementation {can
use a}[need not make the attempt using the] 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}[might] allow the entry call
to be selected in the interim.
["need not" is replaced by other wording. Also "might" is changed to
"can". - Editor.]
Modify 9.6(31):
The time base for delay_relative_statements should be monotonic; it {can
be different than}[need not be] the [same] time base as used for
Calendar.Clock.
Modify 9.8(3):
Each task_name is expected to be of any task type; [they need not all be of
the same]{each can be of a different} task type.
Modify 9.10.1(25/5):
Specifying the Parallel_Calls aspect to be True for a
subprogram indicates that the subprogram can be safely called
in parallel. Conflict checks (if required by the
Conflict_Check_Policy in effect) are made on the subprogram
assuming that multiple concurrent calls exist. Such checks
[need not be repeated at each]{can then be omitted on a} call of the
subprogram in a parallel iteration context.
Modify 10.1.3(11):
In contrast, a subprogram_body_stub [need not be]{can be defined without
it being} the completion of a previous declaration, in which case the
_stub declares the subprogram. If the _stub is a completion, it shall be
the completion of a subprogram_declaration or
generic_subprogram_declaration. The profile of a subprogram_body_stub that
completes a declaration shall conform fully to that of the declaration.
Modify 10.2.1(11.2/5):
* The partial view of a private type or private extension, a
protected type without entry_declarations, 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
entry_declarations 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 [need not]{may} be specified [to have preelaborable
initialization]{with Preelaborable_Initialization False}, even
if the actual type in an instance has preelaborable initialization.
Modify 11.4.2(27/3):
An implementation [need not allow]{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}[could] produce
a different value. Similarly, an implementation [need not allow]{may
disallow} the specification of an assertion expression that is checked as
part of a call on or return from a callable entity 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) C
{can}[could] produce a different value than [it would if]{in the case when}
the first expression had not been evaluated.
[Multiple "need not allow"; two bonus "could"s too - Editor.]
Modify 11.6(5):
* 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}[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.
[Replace "need not" and "need be".]
Modify 12.5.1(15):
For a generic formal type with an unknown_discriminant_part, the actual
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
specification for a representation aspect that contains nonstatic
expressions, unless each nonstatic expression is a name that
statically denotes a constant declared before the entity.
[We tried a large number of rewordings here; this was the easiest that seems
that it might be OK. For the 13.1 wording, I had suggested "never" rather than
"not", to emphasize that these are the most important rules and they apply
even when the Recommended Level of Support is required. Tuck thought that was
overkill.
Other ideas included "may disallow" and "support is optional" - Editor.]
Modify 13.1(23/5):
* An implementation {is not required to}[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.
Modify 13.1(24/3):
* An implementation {is not required to}[need not] support specifying a
nonconfirming representation aspect value if it [could]{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.
[Replace "need not support", "could cause" - Editor.]
Modify 13.1(25/3):
* An implementation {is not required to}[need not] support specifying a
nonconfirming representation aspect value if it [could]{can} cause an
aliased object of an elementary type to have a size other than that
which would have been chosen by default.
[Replace "need not support", "could cause" - Editor.]
Modify 13.1(26/3):
* An implementation {is not required to}[need not] support specifying a
nonconfirming representation aspect value if it [could]{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.
[Replace "need not support", "could cause" - Editor.]
Modify 13.1(27/3):
* An implementation {is not required to}[need not] support specifying a
nonconfirming subtype-specific representation aspect value for an
indefinite or abstract subtype.
Modify 13.1(28/3):
for purposes of these rules, the determination of whether specifying a
representation aspect value for a type [could]{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 [might]{can} be
declared at some point.
[Replace "could cause"; that is used sort of like a technical term, but it isn't
a defined term. "might" also occurs here. This paragraph was left with the
related other paragraphs so that the fix was consistent (there is no "need not"
in this paragraph) - Editor.]
Modify 13.2(8/4):
* 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 record_representation_clause that
applies to the type; the implementation [may, but need not,]{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.
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
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.
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
object of an elementary type {that}[which] cannot be easily loaded and
stored by available machine instructions.
[Replace "need not support", "could enable" - Editor.]
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 {is not required
to}[need not] support a nonconfirming Alignment specified for a derived
untagged by-reference type.
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(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
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.
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(72):
* An implementation {is not required to}[need not] support specified
Component_Sizes that are less than the Size of the component subtype.
Modify 13.4(10):
* An implementation should support at least the internal codes in the
range System.Min_Int .. System.Max_Int. An implementation {is not required
to}[need not] support enumeration_representation_clauses for boolean types.
Modify 13.5.1(22):
* An implementation {is not required to}[need not] support a 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.
Modify 13.11(25.4/2):
* 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]{may have no mechanism for the} deallocation of
individual objects.
Modify 13.12.1(7/2):
The restriction_parameter_argument of a No_Dependence restriction shall be
a name; the name shall have the form of a full expanded name of a library
unit, but [need not denote a]{can be a name that has no corresponding}
unit {currently} present in the environment.
Modify 13.13.1(36/5):
If Stream_Element'Size is not a multiple of System.Storage_Unit, then the
components of Stream_Element_Array [need]{will} not be aliased.
[Tucker says: It really cannot be aliased if Stream_Element'Size is not a
multiple of Storage_Unit - Editor.]
Modify A.4.12(1/5):
A universal text buffer can be used to save and retrieve text of any
language-defined string type. The types used to save and retrieve the text
[need not be the same]{can be different}.
Modify A.5.1(48):
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 A.10(8):
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]{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.
Modify A.10.8(23):
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 A.10.9(36):
The implementation of Put [need not]{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.
Modify A.10.9(37):
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 A.13(16):
{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
as a value of the required subtype.
Modify B.1(41/4):
For each supported convention L other than Intrinsic, an implementation
should support specifying the Import and Export aspects for objects of
L-compatible types and for subprograms, and the Convention aspect for
L-eligible types and for subprograms, presuming the other language has
corresponding features. Specifying the Convention aspect [need
not]{should} be supported for [scalar types, other than] enumeration
types whose internal codes fall within the range 0 .. 2**15-1{, but no
recommendation is made for other scalar types}.
Modify B.3(62.1/3):
An implementation {is not required to}[need not] support specifying the
Convention aspect with convention_identifier C in the following cases:
Modify C.3.2(24/5):
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]{can be
different} for [all]{different} interrupts.
Modify C.7.2(28):
An implementation [need not]{can avoid} actually [create]{creating} the
object corresponding to a task attribute until its value is set to
something other than that of Initial_Value, or until Reference is called
for the task attribute. Similarly, when the value of the attribute is
to be reinitialized to that of Initial_Value, the object may instead be
finalized and its storage reclaimed, to be recreated when needed later.
While the object does not exist, the function Value may simply return
Initial_Value, rather than implicitly creating the object.
Modify D.2.2(17/2):
Implementations are allowed to define other task dispatching policies,
but {are not required to}[need not] support {specifying} more than one
task dispatching policy per partition.
Modify D.2.2(18/2):
An implementation {is not required to}[need not] support pragma
Priority_Specific_Dispatching if it is infeasible to support it in the
target environment.
Modify D.3(15/2):
Implementations are allowed to define other locking policies, but {are
not required to}[need not] support {specifying} more than one locking
policy per partition.
Modify D.4(15/2):
Implementations are allowed to define other queuing policies, but {are
not required to}[need not] support {specifying} more than one queuing
policy per partition.
Modify D.4.1(8/5):
Implementations are allowed to define other admission policies, but {are
not required to}[need not] support {specifying} more than one admission
policy per partition.
Modify D.8(46):
Implementations targeted to machines with word size smaller than 32 bits
[need not support]{may omit support for} the full range and granularity of
the Time and Time_Span types.
[This and the ones like it below are Implementation Permissions, so they
should be using some form of "may" - Editor.]
Modify D.11(10):
An implementation [need not support]{may omit support for}
Asynchronous_Task_Control if it is infeasible to support it in the target
environment.
Modify D.14(28/2):
Implementations targeted to machines with word size smaller than 32 bits
[need not support]{may omit support for} the full range and granularity
of the CPU_Time type.
Modify E.1(13):
In an implementation, the partitions of a distributed program
[need not]{may} be loaded and elaborated [all at the same time]{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.
Modify E.2.3(20/5):
An implementation [need not support]{may omit support for} the
Remote_Call_Interface aspect [nor]{or} the All_Calls_Remote aspect.
Explicit message-based communication between active partitions can be
supported as an alternative to RPC.
Modify E.5(27):
A body for the package System.RPC {is not required to}[need not] be
supplied by the implementation.
Modify G.1.1(54):
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.1.2(46):
The nongeneric equivalent packages [may, but need not,]{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.
Modify G.2(3):
The two modes [need not actually be different]{can be one and the same}.
Modify G.3.1(87/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.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.2(157/2):
Although many operations are defined in terms of operations from
{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):
The dispatching operation set is identified by a set of
dispatching_operation_specifiers. It indicates that the Nonblocking and
global effects of dispatching calls that match one of the specifiers{,
rather than being} [need not be] accounted for by the Nonblocking or global
aspect, [but] are instead to be accounted for by the invoker of the
operation. A dispatching call matches a dispatching_operation_specifier if
the name or prefix of the call statically denotes the same operation(s) as
that of the dispatching_operation_specifier, and at least one of the
objects controlling the call is denoted by, or designated by, a name that
statically names the same object as that denoted by the object_name of the
dispatching_operation_specifier.
!discussion
To summarize the ISO rules from the Directives part 2 (often referred to as the
drafting standard):
Requirements use "shall" preferably, or phrases involving forms of "require",
"has to", or "it is necessary". "Must" is not allowed (it can be
used for external requirements, such as government laws, but that usually
doesn't apply to us).
Recommendations use "should" preferably, or phrases involving forms of
"recommend" or "ought to".
Permissions should use "may" preferably, or phrases using forms of "permit" or
"allow". "Might" is not allowed in this context. Negative forms are not
allowed (no "may not"); permissions must be positive. A quote: "Rather than
using negative permissions, either rewrite the sentence to state what is
permitted, or rewrite as a requirement/recommendation not to do something."
Possibility should use "can", or phrases using forms of "able" or "possible".
ISO has taken this further and does not want to see "might", "could", or
"need" at all; they assume that they are being used in one of the above
contexts. I don't know where "need" comes from (other than the "House Style",
but that's not normative), the Directives never mentions it as a word
to avoid, and in fact it uses the word "needs" with the meaning of desires
repeatedly. But the Directives is clear that one should not use any
words other than the above to express requirements, recommendations, or
permissions.
Note that while some phrases are given meanings, other uses of the words seem
to be allowed by the Directives. For instance, "necessary" is used in many
contexts in the Directives that are not requirements.
We have a particular problem with "need not", used frequently to get around
not being able to say "may not". But negative permissions aren't allowed at
all, in any verbal form. (They have to be reworded positively, or integrated
into the requirements if that's not possible.) This is a problem since many
of our permissions are exceptions to rules stated elsewhere, and those have
to be written negatively. We handle just this problem in this AI; other
wording changes needed are handled in AI12-0438-1, AI12-0439-1, and AI12-0445-1.
--
We could consider making wording changes only for the ISO version (new
commands would be needed in the formatter to support that if is done a lot
- currently, we can only do that on a full paragraph basis or with a few
macros - but new commands should not be hard to define and implement).
However, that would add complications to future maintenance (as we would need
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)
Replace the paragraph:
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 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.
by:
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 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)
Replace the paragraph:
In addition to bounded errors, the language rules define certain kinds
of errors as leading to 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.
by:
In addition to bounded errors, the language rules define certain kinds
of errors as leading to 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)
Replace the paragraph:
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
other_format, format_effector, and graphic_character.
by:
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
other_format, format_effector, and graphic_character.
!corrigendum 3.5.4(5)
Replace the paragraph:
Each simple_expression in a signed_integer_type_definition is
expected to be of any integer type; they need not be of the same
types. The expression in a modular_type_definition is likewise
expected to be of any integer type.
by:
Each simple_expression in a signed_integer_type_definition is
expected to be of any integer type; they can be of different
integer types. The expression in a modular_type_definition is
likewise expected to be of any integer type.
!corrigendum 3.5.4(24)
Replace the paragraph:
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.
by:
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)
Replace the paragraph:
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.
by:
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)
Replace the paragraph:
An implementation may provide nonstandard integer types, descendants of
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 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 explicit_generic_actual_parameters for formal scalar types —
see 12.5.2.
by:
An implementation may provide nonstandard integer types, descendants of
root_integer that are declared outside of the specification of package
Standard, which may have different characteristics than a type defined by an
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 explicit_generic_actual_parameters for formal scalar types —
see 12.5.2.
!corrigendum 3.5.6(7/2)
Replace the paragraph:
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).
by:
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)
Replace the paragraph:
An implementation may provide nonstandard real types, descendants of
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 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 explicit_generic_actual_parameters for formal
scalar types — see 12.5.2.
by:
An implementation may provide nonstandard real types, descendants of
root_real that are declared outside of the specification of package
Standard, which may have different characteristics than a type
defined by a 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 explicit_generic_actual_parameters for formal
scalar types — see 12.5.2.
!corrigendum 3.5.7(5)
Replace the paragraph:
Each simple_expression of a real_range_specification is expected to be of
any real type; the types need not be the same.
by:
Each simple_expression of a real_range_specification is expected to be of
any real type; the types can be different.
!corrigendum 3.5.7(16)
Replace the paragraph:
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.
by:
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)
Replace the paragraph:
An unconstrained_array_definition defines an array type with an
unconstrained first subtype. Each index_subtype_definition defines the
corresponding index subtype to be the subtype denoted by the subtype_mark.
The compound delimiter <> (called a box) of an index_subtype_definition
stands for an undefined range (different objects of the type need not
have the same bounds).
by:
An unconstrained_array_definition defines an array type with an
unconstrained first subtype. Each index_subtype_definition defines the
corresponding index subtype to be the subtype denoted by the subtype_mark.
The compound delimiter <> (called a box) of an index_subtype_definition
stands for an undefined range (different objects of the type can have
different bounds).
!corrigendum 3.9.3(6/4)
Replace the paragraph:
- 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
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.
by:
- 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
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)
Insert new clause:
See the conflict file for the changes.
!corrigendum 6.3(4)
Replace the paragraph:
In contrast to other bodies, a 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 subprogram_declaration or
generic_subprogram_declaration. The profile of a subprogram_body that
completes a declaration shall conform fully to that of the declaration.
by:
In contrast to other bodies, a 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 subprogram_declaration or
generic_subprogram_declaration. The profile of a subprogram_body that
completes a declaration shall conform fully to that of the declaration.
!corrigendum 7.4(8/3)
Replace the paragraph:
A deferred constant declaration for which the Import aspect is True need not
appear in the visible part of a package_specification, and has no full
constant declaration.
by:
A deferred constant declaration for which the Import aspect is True can
appear anywhere that an object_declaration is allowed, and has no full
constant declaration.
!corrigendum 7.6(19/3)
Replace the paragraph:
If an object is assigned the value of that same object, the implementation need
not do anything.
by:
If an object is assigned the value of that same object, the implementation may
omit the entire assignment.
!corrigendum 7.6(21/3)
Replace the paragraph:
- The implementation need not
create an anonymous object if the value being assigned is the result of
evaluating a 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).
by:
- The implementation may avoid creating an anonymous object if the value
being assigned is the result of evaluating a 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)
Replace the paragraph:
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 entry_body
completes without requeuing, then the corresponding calling task may be
made ready without waiting for the entire protected action to complete.
by:
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 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)
Replace the paragraph:
When the entry of a protected object is checked to see whether it is
open, the implementation need not reevaluate
the condition of the corresponding entry_barrier if no variable or
attribute referenced by the 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 condition was last evaluated.
by:
When the entry of a protected object is checked to see whether it is
open, the implementation can bypass reevaluating
the condition of the corresponding entry_barrier if no variable or
attribute referenced by the 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 condition was last evaluated.
!corrigendum 9.5.3(25)
Replace the paragraph:
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.
by:
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)
Replace the paragraph:
The time base for delay_relative_statements should be monotonic; it
need not be the same time base as used for Calendar.Clock.
by:
The time base for delay_relative_statements should be monotonic; it
can be different than the time base as used for Calendar.Clock.
!corrigendum 9.8(3)
Replace the paragraph:
Each task_name is expected to be of any task type; they need not all be of
the same task type.
by:
Each task_name is expected to be of any task type; each can be of a
different task type.
!corrigendum 9.10.1(0)
Insert new clause:
See the conflict file for the changes.
!corrigendum 10.1.3(11)
Replace the paragraph:
In contrast, a subprogram_body_stub need not be the completion of
a previous declaration, in which case the
_stub declares the subprogram. If the _stub is a completion, it shall be
the completion of a subprogram_declaration or
generic_subprogram_declaration. The profile of a subprogram_body_stub that
completes a declaration shall conform fully to that of the declaration.
by:
In contrast, a subprogram_body_stub can be defined without it being the
completion of a previous declaration, in which case the
_stub declares the subprogram. If the _stub is a completion, it shall be
the completion of a subprogram_declaration or
generic_subprogram_declaration. The profile of a subprogram_body_stub that
completes a declaration shall conform fully to that of the declaration.
!corrigendum 10.2.1(11.2/3)
Replace the paragraph:
- The partial view
of a private type or private extension, a protected type without
entry_declarations, a generic formal private type, or a generic formal
derived type, has preelaborable
initialization if and only if the pragma Preelaborable_Initialization has
been applied to them. A protected type with entry_declarations
or a task type never has preelaborable initialization.
by:
- The partial view
of a private type or private extension, a protected type without
entry_declarations, 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 entry_declarations
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)
Replace the paragraph:
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 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) C
could produce a different value than it would if
the first expression had not been evaluated.
by:
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 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) C
can produce a different value than in the case when
the first expression had not been evaluated.
!corrigendum 11.6(5)
Replace the paragraph:
- 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 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.
by:
- An implementation can omit raising 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 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)
Replace the paragraph:
For a generic formal type with an unknown_discriminant_part, the actual
may, but need not, have discriminants, and may be definite or indefinite.
by:
For a generic formal type with an unknown_discriminant_part, the actual
may have discriminants, though that is not required,
and may be definite or indefinite.
!corrigendum 13.1(13/3)
Replace the paragraph:
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.
by:
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)
Replace the paragraph:
- An implementation need not support the
specification for a representation aspect that contains nonstatic
expressions, unless each nonstatic expression is a name that
statically denotes a constant declared before the entity.
by:
- An implementation is not required to support the
specification for a representation aspect that contains nonstatic
expressions, unless each nonstatic expression is a name that
statically denotes a constant declared before the entity.
!corrigendum 13.1(23/5)
Replace the paragraph:
- 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.
by:
- 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)
Replace the paragraph:
- 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.
by:
- 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)
Replace the paragraph:
- 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.
by:
- 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)
Replace the paragraph:
- 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.
by:
- 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)
Replace the paragraph:
- An implementation need not support specifying a
nonconfirming subtype-specific representation aspect value for an
indefinite or abstract subtype.
by:
- 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)
Replace the paragraph:
For purposes of these rules, the determination of whether specifying a
representation aspect value for a type 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.
by:
For purposes of these rules, the determination of whether specifying a
representation aspect value for a type 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)
Replace the paragraph:
- 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 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.
by:
- 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 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)
Replace the paragraph:
- 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.
by:
- 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)
Replace the paragraph:
- 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.
by:
- 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)
Replace the paragraph:
- 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.
by:
- 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)
Replace the paragraph:
- 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.
by:
- 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)
Replace the paragraph:
- 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.
by:
- 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)
Replace the paragraph:
- A nonconfirming size clause for the first subtype of a derived
untagged by-reference type need not be supported.
by:
- 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)
Replace the paragraph:
- An implementation need not support specified
Component_Sizes that are less than the Size of the component subtype.
by:
- An implementation is not required to support specified
Component_Sizes that are less than the Size of the component subtype.
!corrigendum 13.4(10)
Replace the paragraph:
- An implementation should support at least the internal codes in the
range System.Min_Int .. System.Max_Int. An implementation need not
support enumeration_representation_clauses for boolean types.
by:
- 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 enumeration_representation_clauses for boolean types.
!corrigendum 13.5.1(22)
Replace the paragraph:
- An implementation need not support a 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.
by:
- An implementation is not required to support a 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)
Replace the paragraph:
- 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.
by:
- 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)
Replace the paragraph:
The restriction_parameter_argument of a No_Dependence restriction shall be
a name; the name shall have the form of a full expanded name of a library
unit, but need not denote a unit present in the environment.
by:
The restriction_parameter_argument of a No_Dependence restriction shall be
a name; the 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)
Replace the paragraph:
If Stream_Element'Size is not a multiple of System.Storage_Unit, then the
components of Stream_Element_Array need not be aliased.
by:
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)
Insert new clause:
See the conflict file for the changes.
!corrigendum A.5.1(48)
Replace the paragraph:
The nongeneric equivalent packages may, but need not, be actual
instantiations of the generic package for the appropriate predefined type.
by:
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)
Replace the paragraph:
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.
by:
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)
Replace the paragraph:
The nongeneric equivalent packages may, but need not, be actual
instantiations of the generic package for the appropriate predefined type.
by:
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)
Replace the paragraph:
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.
by:
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)
Replace the paragraph:
The nongeneric equivalent packages may, but need not, be actual
instantiations of the generic package for the appropriate predefined type.
by:
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)
Replace the paragraph:
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.
by:
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)
Replace the paragraph:
For each supported convention L other than Intrinsic, an implementation
should support specifying the Import and Export aspects for objects of
L-compatible types and for subprograms, and the Convention aspect for
L-eligible types and for subprograms, presuming the other language has
corresponding features. Specifying the Convention aspect need not be supported
for scalar types, other than enumeration types whose internal codes fall within
the range 0 .. 2**15–1.
by:
For each supported convention L other than Intrinsic, an implementation
should support specifying the Import and Export aspects for objects of
L-compatible types and for subprograms, and the Convention aspect for
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–1, but no recommendation is made for other scalar types.
!corrigendum B.3(62.1/3)
Replace the paragraph:
An implementation need not support specifying the
Convention aspect with convention_identifier C in the following cases:
by:
An implementation is not required to support specifying the
Convention aspect with convention_identifier C in the following cases:
!corrigendum C.3.2(24/5)
Replace the paragraph:
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.
by:
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)
Replace the paragraph:
Implementations are allowed to define other task dispatching policies,
but need not support more than one task dispatching policy per partition.
by:
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)
Replace the paragraph:
An implementation need not support pragma
Priority_Specific_Dispatching if it is infeasible to support it in the
target environment.
by:
An implementation is not required to support pragma
Priority_Specific_Dispatching if it is infeasible to support it in the
target environment.
!corrigendum D.3(15/2)
Replace the paragraph:
Implementations are allowed to define other locking policies, but
need not support more than one locking policy per partition.
by:
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)
Replace the paragraph:
Implementations are allowed to define other queuing policies, but need not
support more than one queuing policy per partition.
by:
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)
Insert new clause:
See the conflict file for the changes.
!corrigendum D.8(46):
Replace the paragraph:
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.
by:
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)
Replace the paragraph:
An implementation need not support Asynchronous_Task_Control if it is
infeasible to support it in the target environment.
by:
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)
Replace the paragraph:
Implementations targeted to machines with word size smaller than 32 bits
need not support the full range and granularity of the CPU_Time type.
by:
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)
Replace the paragraph:
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.
by:
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)
Replace the paragraph:
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.
by:
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)
Replace the paragraph:
A body for the package System.RPC need not be
supplied by the implementation.
by:
A body for the package System.RPC is not required to be
supplied by the implementation.
!corrigendum G.1.1(54)
Replace the paragraph:
The nongeneric equivalent packages may, but need not, be actual
instantiations of the generic package for the appropriate predefined type.
by:
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)
Replace the paragraph:
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.
by:
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)
Replace the paragraph:
The two modes need not actually be different.
by:
The two modes can be one and the same.
!corrigendum G.3.1(87/2)
Replace the paragraph:
The nongeneric equivalent packages may, but need not, be actual
instantiations of the generic package for the appropriate predefined type.
by:
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)
Replace the paragraph:
The nongeneric equivalent packages may, but need not, be actual
instantiations of the generic package for the appropriate predefined type.
by:
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)
Replace the paragraph:
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.
by:
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)
Insert new clause:
See the conflict file for the changes.
!ASIS
No ASIS effect.
!ACATS test
No ACATS test should be needed, no change in meaning is intended and these
are notes anyway.
!appendix
****************************************************************
From: Randy Brukardt
Sent: Saturday, June 11, 2022 2:01 AM
Following are some fixes to the approved changed wording of the various FDIS
AI. There also were a few typos in the AIs (stray brackets, missing words in
Editor's notes) that I won't bother to explain.
I'm not quite done applying the new wording, so there might be another item
or two on Monday, but I'm sending this now so that you can review it and
highlight any issues before I button this up.
[Editor's note: only issues relevant to this AI are shown here; others
are recorded in other relevant AIs.]
---------------
In AI12-0444-1, G.3.1(157/2) reads:
Modify G.3.1(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].
It is bizarre that the package name is in all lower case; we never do that.
I've fixed that to "Numerics.Generic_Complex_Types".
****************************************************************
From: Tucker Taft
Sent: Saturday, June 11, 2022 8:14 AM
All look good to me.
****************************************************************
From: Randy Brukardt
Sent: Tuesday, June 14, 2022 8:36 PM
Having finally finished applying all of the wording changes, I was able to
check the result for words we're not supposed to be using. And surprise,
there still were a dozen or so uses of words we were trying to eliminate.
Some of those were errors applying changes (often cases where there were
two changes in a paragraph, but only one change was applied). The rest are
detailed below.
Please read and comment (if needed) on these ASAP as I will be finishing
this project in the next few days (I hope!!).
[Editor's note: only issues relevant to this AI are shown here; others
are recorded in other relevant AIs.]
----------------
In AI12-0444-1, 13.3(30.1/3) replaces a "need not" with "is not required to".
But there is a second "need not" in the paragraph; we replace that the same way.
-----------------
In AI12-0444-1, all of the paragraph numbers associated with 13.3 are wrong
(they were taken from a normative-only version of the RM, but this clause has
interspersed notes whose paragraph numbers were not counted). The text and
wording changes are unaffected. These have been corrected.
-----------------
13.1(13/5) says:
The specification of certain language-defined aspects 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.
The "need not" needs to be replaced. The usual fix in Chapter 13 is:
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.
I added this to AI12-0444-1.
----------------
A number of Annex M (summary of Implementation-Defined and Implementation
Advice) items contain banned words (as the original text did). I've fixed
these similarly to the base text (and did not otherwise document them, as
is usual as they are considered non-normative).
****************************************************************
From: Jeff Cousins
Sent: Wednesday, June 15, 2022 2:35 AM
Thanks Randy, looks good.
****************************************************************
From: Tucker Taft
Sent: Wednesday, June 15, 2022 5:05 PM
Most seem fine. I have one comment on some awkward wording below.
[Not relevant to this AI and thus omitted - Editor.]
****************************************************************
From: Randy Brukardt
Sent: Tuesday, June 14, 2022 8:36 PM
****************************************************************
From: Randy Brukardt
Sent: Tuesday, June 14, 2022 8:36 PM
****************************************************************
Questions? Ask the ACAA Technical Agent