Version 1.4 of ai12s/ai12-0439-1.txt
!standard 3.3.1(11.1/3) 22-06-13 AI12-0439-1/03
!standard 3.3.1(13/3)
!standard 3.3.1(17)
!standard 3.3.1(21/3)
!standard 3.5.7(10)
!standard 3.7.1(12)
!standard 3.10.2(30)
!standard 4.6(55)
!standard 4.6(56/4)
!standard 5.2(11)
!standard 5.2(12)
!standard 6.1.2(1/5)
!standard 6.1.2(19/5)
!standard 6.4.1(12)
!standard 6.5(5.12/5)
!standard 7.3.1(7)
!standard 7.6(17.1/3)
!standard 8(2/3)
!standard 9.5(21/5)
!standard 9.5.1(17)
!standard 9.7.2(1/2)
!standard 9.7.3(1/2)
!standard 10.2(2)
!standard 10.2(24)
!standard 11.4.2(23.1/3)
!standard 13.11.1(3/3)
!standard 13.11.1(4/3)
!standard 13.11.1(5/3)
!standard 13.13.2(34/3)
!standard 13.14(7.2/5)
!standard A(3/5)
!standard A.3.2(32.6/5)
!standard A.3.5(51.2/5)
!standard A.16(125/3)
!standard A.18(2.1/5)
!standard A.18.2(237.6/5)
!standard A.18.3(151.5/5)
!standard A.18.4(75.5/5)
!standard A.18.7(96.17/5)
!standard A.18.10(218.5/5)
!standard B.4(4)
!standard C.6(20/5)
!standard D.2.6(1/2)
!standard D.8(36/3)
!standard D.10(10.2/5)
!standard H(4)
!standard H.2(1)
!standard H.7(7/5)
!standard H.7.1(13/5)
!class presentation 22-04-21
!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-21
!status received 22-02-18
!priority Critical
!difficulty Medium
!subject Rewordings to replace "might" or "could" with "can" or "may"
!summary
Several paragraphs need to be reworded to avoid using "might".
!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 "might" or "could"? (Yes.)
!recommendation
Replace "might" and "could" with "can" or "may" when that is appropriate.
Other uses of "might" and "could" are found in other AIs, for instance
AI12-0445-1.
!wording
Modify 3.3.1(11.1/3):
* The implicit initial value for a scalar subtype that has the
Default_Value aspect specified is the value of that aspect converted
to the nominal subtype (which {can}[might] raise Constraint_Error - see
4.6, "Type Conversions");
Modify 3.3.1(13/3):
* For a (definite) composite subtype, the implicit initial value of
each component with a default_expression is obtained by evaluation of
this expression and conversion to the component's nominal subtype
(which {can}[might] raise Constraint_Error), unless the component is a
discriminant of a constrained subtype (the previous case), or is in an
excluded variant (see 3.8.1). For each component that does not have a
default_expression, if the composite subtype has the
Default_Component_Value aspect specified, the implicit initial value
is the value of that aspect converted to the component's nominal
subtype; otherwise, any implicit initial values are those determined
by the component's nominal subtype.
Modify 3.3.1(17):
b) If the object_declaration includes an initialization expression, the
(explicit) initial value is obtained by evaluating the expression and
converting it to the nominal subtype (which {can}[might] raise
Constraint_Error - see 4.6).
Modify 3.3.1(21/3):
There is no implicit initial value defined for a scalar subtype unless
the Default_Value aspect has been specified for the type. In the absence of an
explicit initialization or the specification of the Default_Value aspect, a
newly created scalar object {can}[might] have a value that does not belong
to its subtype (see 13.9.1 and H.1).
Modify 3.5.7(10):
A floating_point_definition defines a floating point type whose base
decimal precision is no less than the requested decimal precision. If a
real_range_specification is given, the safe range of the floating point type
(and hence, also its base range) includes at least the values of the simple
expressions given in the real_range_specification. If a
real_range_specification is not given, the safe (and base) range of the type
includes at least the values of the range -10.0**(4*D) .. +10.0**(4*D) where D
is the requested decimal precision. The safe range {can}[might] include other values
as well. The attributes Safe_First and Safe_Last give the actual bounds of the
safe range.
Modify 3.7.1(12):
For the elaboration of a discriminant_constraint, the expressions in the
discriminant_associations are evaluated in an arbitrary order and converted to
the type of the associated discriminant (which {can}[might] raise Constraint_Error -
see 4.6); the expression of a named association is evaluated (and converted)
once for each associated discriminant. The result of each evaluation and
conversion is the value imposed by the constraint for the associated
discriminant.
Modify 3.10.2(30):
If the nominal subtype of X does not statically match the
designated subtype of A, a view conversion of X to the
designated subtype is evaluated (which {can}[might] raise
Constraint_Error - see 4.6) and the value of X'Access
designates that view.
Modify 4.6(55):
* If the target type is tagged, then an assignment to the view assigns
to the corresponding part of the object denoted by the operand;
otherwise, an assignment to the view assigns to the object, after
converting the assigned value to the subtype of the object (which
{can}[might] raise Constraint_Error);
Modify 4.6(56/4):
* Reading the value of the view yields the result of converting the
value of the operand object to the target subtype (which {can}[might] raise
Constraint_Error), except if the object is of an elementary type and
the view conversion is passed as an out parameter; in this latter
case, the value of the operand object may be used to initialize the
formal parameter without checking against any constraint of the target
subtype (as described more precisely in 6.4.1).
Modify 5.2(11):
The value of the expression is converted to the subtype of the target. The
conversion {can}[might] raise an exception (see 4.6).
Modify 5.2(12):
In cases involving controlled types, the target is finalized, and an
anonymous object {can}[might] be used as an intermediate in the assignment, as
described in 7.6.1, "Completion and Finalization". In any case, the converted
value of the expression is then assigned to the target, which consists of the
following two steps:
Modify 6.1.2(1/5):
The Global and Global'Class aspects of a program unit are used to identify
the objects global to the unit that {can}[might] be read or written during
its execution.
Modify 6.1.2(19/5):
The Global aspect for an access-to-subprogram object (or subtype)
identifies the global variables that {can}[might] be referenced when
calling via the object (or any object of that subtype) including
assertion expressions that apply.
Modify 6.4.1(15):
* For any other type, the formal parameter is uninitialized. If
composite, a view conversion of the actual parameter to the
nominal subtype of the formal is evaluated (which {can}[might] raise
Constraint_Error), and the actual subtype of the formal is that of
the view conversion. If elementary, the actual subtype of the
formal is given by its nominal subtype.
Modify 6.5(5.12/5):
For the execution of an extended_return_statement, the
subtype_indication or access_definition is elaborated. This creates the
nominal subtype of the return object. If there is an expression, it is
evaluated and converted to the nominal subtype (which {can}[might] raise
Constraint_Error - see 4.6); the return object is created and the converted
value is assigned to the return object. Otherwise, the return object is
created and initialized by default as for a stand-alone object of its nominal
subtype (see 3.3.1). If the nominal subtype is indefinite, the return object
is constrained by its initial value. A check is made that the value of the
return object belongs to the function result subtype. Constraint_Error is
raised if this check fails.
Modify 7.3.1(7):
For a private_extension_declaration, each inherited subprogram is declared
immediately after the private_extension_declaration if the corresponding
declaration from the ancestor is visible at that place. Otherwise, the
inherited subprogram is not declared for the private extension, though it
{can}[might] be for the full type.
Modify 7.6(17.1/3):
When a function call or aggregate is used to initialize an object, the
result of the function call or aggregate is an anonymous object, which is
assigned into the newly-created object. For such an assignment, the anonymous
object {may}[might] be built in place, in which case the assignment does not
involve any copying. Under certain circumstances, the anonymous object is
required to be built in place. In particular:
[Note: This is a permission, not a possibility, so it should use "may". This
is exactly the reason that ISO doesn't allow "might", because of this
ambiguity.]
Modify 8(2/3):
As explained in Clause 3, a declaration declares a view of an entity and
associates a defining name with that view. The view comprises an
identification of the viewed entity, and possibly additional properties. A
usage name denotes a declaration. It also denotes the view declared by that
declaration, and denotes the entity of that view. Thus, two different usage
names {can}[might] denote two different views of the same entity; in this
case they denote the same entity.
Modify 9.5(21/5):
When aspect Nonblocking is False for an entity, the entity
{can}[might] contain a potentially blocking operation; such an entity
allows blocking. If the aspect is True for an entity, the
entity is said to be nonblocking.
Modify 9.5.1(17):
If the bounded error is detected, Program_Error is raised. If not
detected, the bounded error {can}[might] result in deadlock or a (nested)
protected action on the same target object.
Modify 9.7.2(1/2):
A timed_entry_call issues an entry call that is cancelled if the call (or
a requeue-with-abort of the call) is not selected before the expiration time
is reached. A procedure call may appear rather than an entry call for cases
where the procedure {can}[might] be implemented by an entry.
Modify 9.7.3(1/2):
A conditional_entry_call issues an entry call that is then cancelled if it
is not selected immediately (or if a requeue-with-abort of the call is not
selected immediately). A procedure call may appear rather than an entry call
for cases where the procedure {can}[might] be implemented by an entry.
Modify 10.2(2):
A partition is a program or part of a program that can be invoked from
outside the Ada implementation. For example, on many systems, a partition
{can}[might] be an executable file generated by the system linker. The user can
explicitly assign library units to a partition. The assignment is done in an
implementation-defined manner. The compilation units included in a partition
are those of the explicitly assigned library units, as well as other
compilation units needed by those library units. The compilation units needed
by a given compilation unit are determined as follows (unless specified
otherwise via an implementation-defined pragma, or by some other
implementation-defined means):
["needed" here is a technical term, hopefully included in the "Terms" clause,
so it is OK. - Editor.]
Modify 10.2(24):
The mechanisms for building and running partitions are implementation
defined. These {can}[might] be combined into one operation, as, for
example, in dynamic linking, or "load-and-go" systems.
[Note: The last sentence is marked "Redundant", so an alternative would be to
delete it or move it to the AARM. I don't believe that is necessary. - Editor.]
Modify 11.4.2(23.1/3):
It is a bounded error to invoke a potentially blocking operation (see
9.5.1) during the evaluation of an assertion expression associated with a call
on, or return from, a protected operation. If the bounded error is detected,
Program_Error is raised. If not detected, execution proceeds normally, but if
it is invoked within a protected action, it {can}[might] result in deadlock or a
(nested) protected action.
Modify 13.11.1(3/3):
S'Max_Size_In_Storage_Elements
Denotes the maximum value for Size_In_Storage_Elements that
{can}[could] be requested by the implementation via Allocate
for an access type whose designated subtype is S. The value of
this attribute is of type universal_integer.
Modify 13.11.1(4/3):
S'Max_Alignment_For_Allocation
Denotes the maximum value for Alignment that {can}[could] be
requested by the implementation via Allocate for an access
type whose designated subtype is S. The value of this
attribute is of type universal_integer.
Modify 13.11.1(5/3):
For a type with access discriminants, if the implementation allocates
space for a coextension in the same pool as that of the object having the
access discriminant, then these attributes account for any calls on Allocate
that {can}[could] be performed to provide space for such coextensions.
[I considered using "are performed" instead, but "can" is consistent with the
preceding paragraphs - Editor.]
Modify 13.13.2(34/3):
First reads the external tag from Stream and determines the
corresponding internal tag (by calling
Tags.Descendant_Tag(String'Input(Stream), S'Tag) which {can}[might]
raise Tag_Error - see 3.9) and then dispatches to the
subprogram denoted by the Input attribute of the specific type
identified by the internal tag; returns that result. If the
specific type identified by the internal tag is abstract,
Constraint_Error is raised.
Modify 13.14(7.2/5):
* At the freezing point of the entity associated with an
aspect_specification, any static expressions within the
aspect_specification cause freezing, as do expressions or names in
aspect_definitions for representation aspects, or operational aspects
that have a corresponding operational attribute. Similarly, if an
aspect_definition for an operational aspect, other than an assertion
aspect, {can}[could] affect the Name Resolution, Static Semantics, or
Legality Rules of a subsequent construct, then any expressions or
names within the aspect_definition cause freezing at the freezing
point of the associated entity. Any static expressions within an
aspect_specification also cause freezing at the end of the immediately
enclosing declaration list. For the purposes of this rule, if there is
no declared entity associated with an aspect_specification, the
freezing point is considered to occur immediately following the
aspect_specification.
Modify A(3/5):
The implementation shall ensure that concurrent calls on any two (possibly
the same) language-defined subprograms perform as specified, so long as all
pairs of objects (one from each call) that are either denoted by parameters
that {can}[could] be passed by reference, or are designated by parameters of
an access type, are nonoverlapping.
Modify A.3.2(32.6/5):
Is_NFKC True if Item {can}[could] be present in a string normalized to
Normalization Form KC (as defined by Clause 21 of ISO/IEC
10646:2017); this includes all characters except those with
positions 160, 168, 170, 175, 178, 179, 180, 181, 184, 185,
186, 188, 189, and 190.
Modify A.3.5(51.2/5):
Returns True if the Wide_Character designated by Item {can}[could] be
present in a string normalized to Normalization Form KC (as
defined by Clause 21 of ISO/IEC 10646:2017), otherwise returns False.
Modify A.16(125/3):
Start_Search and Search should raise Name_Error if Pattern is
malformed, but not if it {can}[could] represent a file in the directory
but does not actually do so.
Modify A.18(2.1/5):
Some operations of the language-defined child units of Ada.Containers
have access-to-subprogram parameters. To ensure such operations are
well-defined, they guard against certain actions by the designated subprogram.
An action on a container that {can}[might] add or remove an element is
considered to tamper with cursors, and these are prohibited during all such
operations. An action on a container that {can}[might] replace an element
with one of a different
size is considered to tamper with elements, and these are prohibited during
certain of such operations. The details of the specific actions that are
considered to tamper with cursors or elements are defined for each child unit
of Ada.Containers.
Modify A.18.2(237.6/5):
If a stable vector is declared with the Base discriminant designating
a pre-existing ordinary vector, the stable vector represents a stabilized view
of the underlying ordinary vector, and any operation on the stable vector is
reflected on the underlying ordinary vector. While a stabilized view exists,
any operation that tampers with elements performed on the underlying vector is
prohibited. The finalization of a stable vector that provides such a view
removes this restriction on the underlying ordinary vector (though some other
restriction {can}[might] exist due to other concurrent iterations or stabilized
views).
Modify A.18.3(151.5/5):
If a stable list is declared with the Base discriminant designating a
pre-existing ordinary list, the stable list represents a stabilized view of
the underlying ordinary list, and any operation on the stable list is
reflected on the underlying ordinary list. While a stabilized view exists, any
operation that tampers with elements performed on the underlying list is
prohibited. The finalization of a stable list that provides such a view
removes this restriction on the underlying ordinary list (though some other
restriction {can}[might] exist due to other concurrent iterations or stabilized
views).
Modify A.18.4(75.5/5):
If a stable map is declared with the Base discriminant designating a
pre-existing ordinary map, the stable map represents a stabilized view of the
underlying ordinary map, and any operation on the stable map is reflected on
the underlying ordinary map. While a stabilized view exists, any operation
that tampers with elements performed on the underlying map is prohibited. The
finalization of a stable map that provides such a view removes this
restriction on the underlying ordinary map (though some other restriction
{can}[might] exist due to other concurrent iterations or stabilized views).
Modify A.18.7(96.17/5):
If a stable set is declared with the Base discriminant designating a
pre-existing ordinary set, the stable set represents a stabilized view of the
underlying ordinary set, and any operation on the stable set is reflected on
the underlying ordinary set. While a stabilized view exists, any operation
that tampers with cursors performed on the underlying set is prohibited. The
finalization of a stable set that provides such a view removes this
restriction on the underlying ordinary set (though some other restriction
{can}[might] exist due to other concurrent iterations or stabilized views).
Modify A.18.10(218.5/5):
If a stable tree is declared with the Base discriminant designating a
pre-existing ordinary tree, the stable tree represents a stabilized view of
the underlying ordinary tree, and any operation on the stable tree is
reflected on the underlying ordinary tree. While a stabilized view exists, any
operation that tampers with elements performed on the underlying tree is
prohibited. The finalization of a stable tree that provides such a view
removes this restriction on the underlying ordinary tree (though some other
restriction {can}[might] exist due to other concurrent iterations or stabilized
views).
Modify B.4(4):
* A set of types and constants reflecting external data representations
such as {can}[might] be found in files or databases, allowing COBOL-generated
data to be read by an Ada program, and Ada-generated data to be read
by COBOL programs
Modify C.6(20/5):
The external effect of a program (see 1.1.3) is defined to include each
read and update of a volatile or atomic object. The implementation shall not
generate any memory reads or updates of atomic or volatile objects other than
those specified by the program. However, there may be target-dependent cases
where reading or writing a volatile but nonatomic object (typically a
component) necessarily involves reading and/or writing neighboring storage,
and that neighboring storage {can}[might] overlap a volatile object.
Modify D.2.6(1/2):
The deadline of a task is an indication of the urgency of the task; it
represents a point on an ideal physical time line. The deadline
{can}[might] affect how resources are allocated to the task.
Modify D.8(36/3):
The implementation shall document any aspects of the external environment
that {can}[could] interfere with the clock behavior as defined in this
subclause.
Modify D.10(10.2/5):
It is a bounded error for two or more tasks to call Suspend_Until_True
on the same Suspension_Object concurrently. For each task, Program_Error
{can}[might] be raised, the task {can}[might] proceed without suspending,
or the task {can}[might] suspend, potentially indefinitely. The state of
the suspension object {can}[might] end up either True or False.
Modify H(4):
* Restricting language constructs whose usage {can}[might] complicate the
demonstration of program correctness
Modify H.2(1):
The implementation shall document the range of effects for each situation
that the language rules identify as either a bounded error or as having an
unspecified effect. If the implementation can constrain the effects of
erroneous execution for a given construct, then it shall document such
constraints. The documentation {may}[might] be provided either independently
of any compilation unit or partition, or as part of an annotated listing
for a given unit or partition. See also 1.1.3, and 1.1.2.
[This is really a permission (not a possibility), thus the use of "may" - Editor.]
Modify H.7(7/5):
The Global aspect for a subtype identifies the global variables that
{can}[might] be referenced during default initialization, adjustment as part
of assignment, finalization of an object of the subtype, or conversion to the
subtype, including the evaluation of any assertion expressions that apply.
If not specified for the first subtype of a derived type, the aspect defaults
to that of the ancestor subtype; if not specified for a nonderived composite
first subtype the aspect defaults to that of the enclosing library unit; if
not specified for a nonderived elementary first subtype (or scalar base
subtype), the aspect defaults to null in the absence of a predicate (or when
the predicate is statically True), and to that of the enclosing library unit
otherwise. If not specified for a nonfirst subtype S, the Global aspect
defaults to that of the subtype identified in the subtype_indication
defining S.
Modify H.7.1(13/5):
The formal parameter set is identified by a set of
formal_parameter_names. Alternatively, the reserved word null may be used to
indicate none of the generic formal parameters, or all to indicate all of the
generic formal parameters, of any enclosing generic unit (or visible formal
package) {can}[might] be used within the execution of the operation. If there is no
formal parameter set specified for an entity declared within a generic unit,
it defaults to all.
!discussion
The ISO rules from the Directives part 2 (often referred to as the
drafting standard) are summarized in AI12-0445-1.
We have a lot of material that talks about consequences of rules; the
Directives are silent on wording for such cases (in particular, when there is no
optionality in the consequences; one could use "can" for possible
consequences). So we have to invent wording, but it has to avoid any phrasing
that looks like it might be a requirement. That is a very difficult thing to
accomplish.
---
There are 68 occurrences of "might" and 16 occurrences of "could" in normative
wording.
Most of these occurrences are discussing possibilities (often possible
consequences), so a simple replacement with "can" is suggested.
---
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.
!comment Not all paragraphs are given in Corrigendum sections.
!corrigendum 6.1.2(0)
Insert new clause:
See the conflict file for the changes.
!corrigendum 9.5(17/3)
Insert after the paragraph:
In addition to the places where Legality Rules normally apply (see 12.3),
these rules also apply in the private part of an instance of a generic unit.
the new paragraphs:
Static Semantics
For a program unit, task entry, formal package, formal
subprogram, formal object of an anonymous access-to-subprogram type,
enumeration literal, and for a subtype (including a formal subtype), the
following language-defined operational aspect is defined:
<<The rest of the new text is found in the conflict file.>>
!corrigendum 13.14(7.2/3)
Replace the paragraph:
- At the freezing point of the entity associated with an
aspect_specification, any expressions or names within the
aspect_specification cause freezing. Any static expressions within an
aspect_specification also cause freezing at the end of the immediately
enclosing declaration list.
by:
- At the freezing point of the entity associated with an
aspect_specification, any static expressions within the
aspect_specification cause freezing, as do expressions or names in
aspect_definitions for representation aspects, or operational aspects
that have a corresponding operational attribute. Similarly, if an
aspect_definition for an operational aspect, other than an
assertion aspect, can affect the Name Resolution, Static Semantics, or
Legality Rules of a subsequent construct, then any expressions or names
within the aspect_definition cause freezing at the freezing point of the
associated entity. Any static expressions within an aspect_specification
also cause freezing at the end of the immediately enclosing declaration list.
For the purposes of this rule, if there is no declared entity associated with
an aspect_specification, the freezing point is considered to occur
immediately following the aspect_specification.
!corrigendum A(3/4)
Replace the paragraph:
The implementation shall ensure that each language-defined subprogram
is reentrant in the sense that concurrent calls on any language-defined
subprogram perform as specified, so long as all objects that are denoted by
parameters that could be passed by reference or designated by parameters of
an access type are nonoverlapping.
by:
The implementation shall ensure that concurrent calls on any two (possibly the
same) language-defined subprograms perform as specified, so long as all pairs of
objects (one from each call) that are either denoted by parameters that can
be passed by reference, or are designated by parameters of an access type, are
nonoverlapping.
!corrigendum A.3.2(32.5/3)
Insert after the paragraph:
- Is_Space
-
True if Item is a character with position 32 (' ') or 160 (No_Break_Space).
the new paragraph:
- Is_NFKC
-
True if Item can be present in a string normalized to Normalization
Form KC (as defined by Clause 21 of ISO/IEC 10646:2017); this includes
all characters except those with positions 160, 168, 170, 175, 178, 179,
180, 181, 184, 185, 186, 188, 189, and 190.
!corrigendum A.3.5(51/3)
Insert after the paragraph:
Returns True if the Wide_Character designated by Item is categorized as
separator_space, otherwise returns False.
the new paragraphs:
function Is_NFKC (Item : Wide_Character) return Boolean;
Returns True if the Wide_Character designated by Item can be present
in a string normalized to Normalization Form KC (as defined by Clause
21 of ISO/IEC 10646:2017), otherwise returns False.
!corrigendum A.18(2/2)
Insert after the paragraph:
A variety of sequence and associative containers are provided. Each container
includes a cursor type. A cursor is a reference to an element within a
container. Many operations on cursors are common to all of the containers. A
cursor referencing an element in a container is considered to be overlapping
with the container object itself.
the new paragraph:
Some operations of the language-defined child units of Ada.Containers
have access-to-subprogram parameters. To ensure such operations are
well-defined, they guard against certain actions by the designated
subprogram. An action on a container that can add or remove an
element is considered to tamper with cursors, and these are
prohibited during all such operations. An action on a container that can
replace an element with one of a different size is considered to
tamper with elements, and these are prohibited during certain of such
operations. The details of the specific actions that are considered to
tamper with cursors or elements are defined for each child unit of
Ada.Containers.
!corrigendum C.6(20)
Replace the paragraph:
The external effect of a program (see 1.1.3) is defined to include each read
and update of a volatile or atomic object. The implementation shall not
generate any memory reads or updates of atomic or volatile objects other than
those specified by the program. However, there may be
target-dependent cases where reading or writing a volatile but nonatomic
object (typically a component) necessarily involves reading and/or
writing neighboring storage, and that neighboring storage may overlap
a volatile object.
by:
The external effect of a program (see 1.1.3) is defined to include each read
and update of a volatile or atomic object. The implementation shall not
generate any memory reads or updates of atomic or volatile objects other than
those specified by the program. However, there may be
target-dependent cases where reading or writing a volatile but nonatomic
object (typically a component) necessarily involves reading and/or
writing neighboring storage, and that neighboring storage can overlap
a volatile object.
!corrigendum D.10(10.1/3)
Insert after the paragraph:
The procedure Suspend_Until_True_And_Set_Deadline blocks the calling task
until the state of the object S is True; at that point the task becomes
ready with a deadline of Ada.Real_Time.Clock + TS, and the state of the
object becomes False. Program_Error is raised upon calling
Suspend_Until_True_And_Set_Deadline if another task is already waiting on
that suspension object. Suspend_Until_True_And_Set_Deadline is a potentially
blocking operation.
the new paragraph:
Bounded (Run-Time) Errors
It is a bounded error for two or more tasks to call Suspend_Until_True
on the same Suspension_Object concurrently. For each task, Program_Error
can be raised, the task can proceed without suspending, or the task
can suspend, potentially indefinitely. The state of the suspension
object can end up either True or False.
!corrigendum H.7(0)
Insert new clause:
See the conflict file for the changes.
!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
****************************************************************
Questions? Ask the ACAA Technical Agent