Version 1.5 of ai12s/ai12-0440-1.txt
!standard 1.1.3(22) 22-06-13 AI12-0440-1/03
!standard 2.7(6)
!standard 2.9(3)
!standard 3.2.2(13)
!standard 3.9.4(19/2)
!standard 3.9.4(27/2)
!standard 3.10.2(37/2)
!standard 4.3.3(33/5)
!standard 4.7(5)
!standard 4.8(14)
!standard 5.4(14)
!standard 6.2(15/4)
!standard 6.4(31)
!standard 6.6(7)
!standard 6.7(7/2)
!standard 7.3.1(10)
!standard 7.3.1(19)
!standard 7.5(21)
!standard 8.5.5(5)
!standard 9(11/5)
!standard 9.3(12)
!standard 9.5.1(19/5)
!standard 9.5.1(20)
!standard 9.5.1(23/5)
!standard 9.5.2(29/2)
!standard 9.5.2(30)
!standard 9.6(33)
!standard 9.7.3(4)
!standard 10.1.2(32/5)
!standard 10.1.3(22/5)
!standard 10.2(31)
!standard 10.2(32)
!standard 11.4.3(1)
!standard 11.4.3(11)
!standard 13.8(9)
!standard 13.9.2(12/4)
!standard 13.11(35)
!standard 13.11(38/3)
!standard 13.11.3(9/3)
!standard 13.11.4(34/3)
!standard A.3.5(63/3)
!standard A.7(16)
!standard A.10.5(52)
!standard A.18.2(263/2)
!standard B.1(42/3)
!standard B.1(44/3)
!standard B.3.1(58)
!standard B.3.1(59)
!standard B.4(100)
!standard C.3.1(22/3)
!standard C.6(26/5)
!standard D.1(29/3)
!standard D.8(50/3)
!standard D.8(50/3)
!standard E(7)
!standard E.2.2(20/3)
!standard H(6)
!standard H.1(9)
!standard H.4(28/2)
!standard H.6(17/2)
!standard J.10(8/2)
!standard J.15.1(6/3)
!class presentation 22-04-26
!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-26
!status received 22-02-18
!priority Critical
!difficulty Medium
!subject Rewordings of notes to replace other words with "can"
!summary
Several notes paragraphs need to be reworded to avoid using "might", "may",
"should", "could", or "need".
!question
ISO comment #16 includes a mention of the fact that the drafting rules do not
allow any requirements, recommendations, or permissions in notes. We of course
follow the spirit of that rule, but we do not follow the letter, which does
not allow any phrasing that might be mistaken for one of these things.
We also need to reword many notes to avoid words and phrases that aren't
allowed at all ("must", "might", "could", "need") - see AI12-04yy-1.
There are many notes that need rewording, and for many of them the rewordings
are complex.
Should we fix any uses of words not allowed in notes? (Yes.)
!recommendation
Replace "might", "may", "should", "could", or "need" with "can" when that is
appropriate. Other uses of these words in notes are replaced in AI12-0442-1.
!wording
Modify 1.1.3(22):
NOTE The above requirements imply that an implementation conforming
to this Standard {can}[may] support some of the capabilities required by a
Specialized Needs Annex without supporting all required capabilities.
["required" is really close to a bad word, but I don't see how one can
interpret requirements without mentioning them - Editor.]
Modify part of 2.7(6):
-- a long comment {can}[may] be split onto
-- two or more consecutive lines
Modify 2.9(3):
NOTE The reserved words appear in lower case boldface in this
International Standard, except when used in the designator of an
attribute (see 4.1.4). Lower case boldface is also used for a reserved
word in a string_literal used as an operator_symbol. This is merely a
convention - programs {can}[may] be written in whatever typeface is
desired and available.
Modify 3.2.2(13):
NOTE A scalar_constraint {can}[may] be applied to a subtype of an
appropriate scalar type (see 3.5, 3.5.9, and J.3), even if the subtype
is already constrained. On the other hand, a composite_constraint {can}[may]
be applied to a composite subtype (or an access-to-composite subtype)
only if the composite subtype is unconstrained (see 3.6.1 and 3.7.1).
Modify 3.9.4(19/2):
NOTE Nonlimited interface types have predefined nonabstract equality
operators. These {can}[may] be overridden with user-defined abstract equality
operators. Such operators will then require an explicit overriding for
any nonabstract descendant of the interface.
Modify 3.9.4(27/2):
The Synchronized_Queue interface inherits the four dispatching operations
from Queue and adds two additional dispatching operations, which wait if
necessary rather than raising the Queue_Error exception. This synchronized
interface {can}[may] only be implemented by a task or protected type, and
as such ensures safe concurrent access.
Modify 3.10.2(37/2):
NOTE 5 The Access attribute for subprograms and parameters of an
anonymous access-to-subprogram type {can be used}[may] together [be used]
to implement "downward closures" - that is, to pass a more-nested
subprogram as a parameter to a less-nested subprogram, as
{can}[might] be appropriate for an
iterator abstraction or numerical integration. Downward closures can
also be implemented using generic formal subprograms (see 12.6). Note
that Unchecked_Access is not allowed for subprograms.
[Also moved "be used" to read better - Editor.]
Modify 4.3.3(33/5):
NOTE 1 In an array_aggregate delimited by parentheses, positional
notation {can}[may] only be used with two or more expressions; a single
expression in parentheses is interpreted as a parenthesized
expression. An array_aggregate delimited by square brackets {can}[may]
be used to specify an array with a single component.
Modify 4.7(5):
NOTE When a given context does not uniquely identify an expected
type, a qualified_expression can be used to do so. In particular, if
an overloaded name or aggregate is passed to an overloaded subprogram,
it {can}[might] be necessary to qualify the operand to resolve its type.
Modify 4.8(14):
NOTE 3 As explained in 13.11, "Storage Management", the storage for
an object allocated by an allocator comes from a storage pool
(possibly user defined). The exception Storage_Error is raised by an
allocator if there is not enough storage. Instances of
Unchecked_Deallocation {can}[may] be used to explicitly reclaim storage.
Modify 5.4(14):
NOTE The execution of a case_statement chooses one and only one
alternative. Qualification of the expression of a case_statement by a
static subtype can often be used to limit the number of choices that
{can}[need] be given explicitly.
Modify 6.2(15/4):
NOTE 3 A formal parameter of mode out {can}[might] be uninitialized
at the start of the subprogram_body (see 6.4.1).
Modify 6.4(31):
-- Set(Red) would be ambiguous since Red {can}[may]
-- denote a value either of type Color or of type Light
Modify 6.6(7):
NOTE The operators "+" and "-" are both unary and binary operators,
and hence {can}[may] be overloaded with both one- and two-parameter
functions.
Modify 6.7(7/2):
procedure Simplify(Expr : in out Expression) is null; --
--
Modify 7.3.1(10):
NOTE 1 Because a partial view and a full view are two different
views of one and the same type, outside of the defining package the
characteristics of the type are those defined by the visible part.
Within these outside program units the type is just a private type or
private extension, and any language rule that applies only to another
class of types does not apply. The fact that the full declaration
{can}[might] implement a private type with a type of a particular class (for
example, as an array type) is relevant only within the declarative
region of the package itself including any child units.
Modify 7.3.1(19):
The explicitly declared operator "<" hides the predefined operator "<"
implicitly declared by the full_type_declaration. Within the body of
the function, an explicit conversion of X and Y to the subtype Natural
is necessary to invoke the "<" operator of the parent type.
Alternatively, the result of the function {can}[could] be written as
not (X >= Y), since the operator ">=" is not redefined.
Modify 7.5(21):
NOTE 3 Notes on the example: In the example above, an outside
subprogram making use of IO_Package {can}[may] obtain a file name by calling
Open and later use it in calls to Read and Write. Thus, outside the
package, a file name obtained from Open acts as a kind of password;
its internal properties (such as containing a numeric value) are not
known and no other operations (such as addition or comparison of
internal names) can be performed on a file name. Most importantly,
clients of the package cannot make copies of objects of type File_Name.
Modify 8.5.5(5):
NOTE Although the properties of the new view are the same as those
of the renamed view, the place where the
generic_renaming_declaration occurs {can}[may] affect the legality of
subsequent renamings and instantiations that denote the
generic_renaming_declaration, in particular if the renamed generic
unit is a library unit (see 10.1.1).
Modify 9(11/5):
NOTE Concurrent task execution {can}[may] be implemented on multicomputers,
multiprocessors, or with interleaved execution on a single physical
processor. On the other hand, whenever an implementation can determine
that the required semantic effects can be achieved when parts of the
execution of a single logical thread of control are performed by
different physical processors acting in parallel, it {can}[may] choose to
perform them in this way.
Modify 9.3(12):
NOTE 3 The rules given for the collective completion of a group of
tasks all blocked on select_statements with open
terminate_alternatives ensure that the collective completion can occur
only when there are no remaining active tasks that {can}[could]
call one of the tasks being collectively completed.
Modify 9.5.1(19/5):
NOTE 1 If two tasks both try to start a protected action on a
protected object, and at most one is calling a protected nonexclusive
function, then only one of the tasks can proceed. Although the other
task cannot proceed, it is not considered blocked, and it {can}[might] be
consuming processing resources while it awaits its turn. Unless there
is an admission policy (see D.4.1) in effect, there is no
language-defined ordering or queuing presumed for tasks competing to
start a protected action - on a multiprocessor such tasks {can}[might] use
busy-waiting; for further monoprocessor and multiprocessor
considerations, see D.3, "Priority Ceiling Locking".
Modify 9.5.1(20):
NOTE 2 The body of a protected unit {can}[may] contain declarations and
bodies for local subprograms. These are not visible outside the
protected unit.
Modify 9.5.1(23/5):
NOTE 5 The aspect Nonblocking can be specified True on the
definition of a protected unit in order to reject most attempts to use
potentially blocking operations within the protected unit (see 9.5).
The pragma Detect_Blocking {can}[may] be used to ensure that any remaining
executions of potentially blocking operations during a protected
action raise Program_Error. See H.5.
Modify 9.5.2(29/2):
NOTE 3 A return statement (see 6.5) or a requeue_statement (see
9.5.4) {can}[may] be used to complete the execution of an accept_statement or
an entry_body.
Modify 9.5.2(30):
NOTE 4 The condition in the entry_barrier {can}[may] reference anything
visible except the formal parameters of the entry. This includes the
entry index (if any), the components (including discriminants) of the
protected object, the Count attribute of an entry of that protected
object, and data global to the protected unit.
Modify 9.6(33):
NOTE 2 A delay_statement {can}[may] be executed by the environment task;
consequently delay_statements {can}[may] be executed as part of the
elaboration of a library_item or the execution of the main subprogram.
Such statements delay the environment task (see 10.2).
Modify 9.7.3(4):
NOTE A conditional_entry_call {can}[may] briefly increase the Count
attribute of the entry, even if the conditional call is not selected.
Modify 9.11(1):
The following example defines a buffer protected object to smooth variations
between the speed of output of a producing task and the speed of input of some
consuming task. For instance, the producing task {can}[might] have the following
structure:
Modify 9.11(4):
and the consuming task {can}[might] have the following structure:
Modify 10.1.2(32/5):
The limited_with_clause {can}[may] be used to support mutually dependent abstractions
that are split across multiple packages. In this case, an employee is assigned
to a department, and a department has a manager who is an employee. If a
with_clause with the reserved word private appears on one library unit and
mentions a second library unit, it provides visibility to the second library
unit, but restricts that visibility to the private part and body of the first
unit. The compiler checks that no use is made of the second unit in the
visible part of the first unit.
Modify 10.1.3(22/5):
Example showing how the body of procedure Inner {can}[may] be turned into a subunit
by rewriting the package body as follows (with the declaration of Parent
remaining the same):
Modify 10.2(31):
NOTE 1 An implementation {can}[may] provide inter-partition communication
mechanism(s) via special packages and pragmas. Standard pragmas for
distribution and methods for specifying inter-partition communication
are defined in Annex E, "Distributed Systems". If no such mechanisms
are provided, then each partition is isolated from all others, and
behaves as a program in and of itself.
Modify 10.2(32):
NOTE 2 Partitions are not required to run in separate address
spaces. For example, an implementation {can}[might] support dynamic linking
via the partition concept.
Modify 11.4.3(1):
Exception handling {can}[may] be used to separate the detection of an error from the
response to that error:
Modify 11.4.3(11):
In the above example, the File_System package contains information about
detecting certain exceptional situations, but it does not specify how to
handle those situations. Procedure Main specifies how to handle them; other
clients of File_System {can}[might] have different handlers, even though the
exceptional situations arise from the same basic causes.
Modify 13.8(9):
NOTE 1 An implementation {can}[may] provide implementation-defined pragmas
specifying register conventions and calling conventions.
Modify 13.9.2(12/4):
NOTE 2 Determining whether X is normal and has a valid
representation as part of the evaluation of X'Valid is not considered
to include an evaluation of X; hence, it is not an error to check the
validity of an object that is invalid or abnormal. Determining whether
X satisfies the predicates of its nominal subtype {can}[may] include an
evaluation of X, but only after it has been determined that X has a
valid representation.
Modify 13.11(35):
Another access type {can}[may] be added to an existing storage pool, via:
Modify 13.11(38/3):
As usual, a derivative of Root_Storage_Pool {can}[may] define additional operations.
For example, consider the Mark_Release_Pool_Type defined in 13.11.6, that has
two additional operations, Mark and Release, the following is a possible use:
Modify 13.11.3(9/3):
NOTE Default_Storage_Pool {can}[may] be used with restrictions
No_Coextensions and No_Access_Parameter_Allocators (see H.4) to ensure
that all allocators use the default pool.
Modify 13.11.4(34/3):
NOTE 2 A user-defined storage pool type that supports subpools {can}[may]
define additional subpool constructors similar to Create_Subpool
(these typically will have additional parameters).
Modify A.3.5(63/3):
NOTE 1 The results returned by these functions {can}[may] depend on which
particular version of the 10646 standard is supported by the
implementation (see 2.1).
Modify A.7(16):
NOTE 2 A bidirectional device can often be modeled as two sequential
files associated with the device, one of mode In_File, and one of mode
Out_File. An implementation {can}[may] restrict the number of files
that {can}[may] be associated with a given external file.
Modify A.10.5(52):
NOTE A page terminator is always skipped whenever the preceding line
terminator is skipped. An implementation {can}[may] represent the combination
of these terminators by a single character, provided that it is
properly recognized on input.
Modify A.18.2(263/2):
NOTE 1 All elements of a vector occupy locations in the internal
array. If a sparse container is required, a Hashed_Map {can}[should]
be used rather than a vector.
Modify B.1(42/3):
NOTE 1 Implementations {can}[may] place restrictions on interfacing
aspects; for example, requiring each exported entity to be declared at
the library level.
Modify B.1(44/3):
NOTE 3 To obtain "call-back" to an Ada subprogram from a foreign
language environment, the Convention aspect {can}[should] be specified both
for the access-to-subprogram type and the specific subprogram(s) to
which 'Access is applied.
Modify B.3.1(58):
NOTE New_Char_Array and New_String {can}[might] be implemented either
through the allocation function from the C environment ("malloc") or
through Ada dynamic memory allocation ("new"). The key points are
Modify B.3.1(59):
the returned value (a chars_ptr) is represented as a C "char " so
that it {can}[may] be passed to C functions;
Modify B.4(100):
NOTE 2 If an Ada subprogram is exported to COBOL, then a call from
COBOL call {can}[may] specify either "BY CONTENT" or "BY REFERENCE".
Modify C.3.1(22/3):
NOTE 1 The Attach_Handler aspect {can}[may] provide static attachment of
handlers to interrupts if the implementation supports preelaboration
of protected objects. (See C.4.)
Modify C.6(26/5):
NOTE 3 When mapping an Ada object to a memory-mapped hardware
register, the Ada object {can}[should] be declared atomic to ensure that the
compiler will read and write exactly the bits of the register as
specified in the source code and no others.
Modify D.1(29/3):
NOTE 3 An implementation {can}[may] provide a nonstandard mode in which
tasks inherit priorities under conditions other than those specified
above.
Modify D.8(50/3):
NOTE 1 The rules in this subclause do not imply that the
implementation can protect the user from operator or installation
errors {that can}[which could] result in the clock being set incorrectly.
Modify E(7):
NOTE 1 The partitions comprising a program {can}[may] be executed on
differently configured distributed systems or on a nondistributed
system without requiring recompilation. A distributed program {can}[may] be
partitioned differently from the same set of library units without
recompilation. The resulting execution is semantically equivalent.
Modify E.2.2(20/3):
NOTE 3 A remote access type {can}[may] designate a class-wide synchronized,
protected, or task interface type.
Modify H(6):
NOTE The Valid attribute (see 13.9.2) is also useful in addressing
these needs, to avoid problems that {can}[could] otherwise arise from
scalars that have values outside their declared range constraints.
["Needs" is OK here, the word is used that way in the Directives, we ought to
be allowed to do the same. Replaced "could" - Editor.]
Modify H.1(9):
NOTE 3 The use of pragma Normalize_Scalars in conjunction with
Pragma Restrictions(No_Exceptions) {can}[may] result in erroneous execution
(see H.4).
Modify H.4(28/2):
NOTE Uses of restriction_parameter_identifier No_Dependence defined
in 13.12.1: No_Dependence => Ada.Unchecked_Deallocation and
No_Dependence => Ada.Unchecked_Conversion {can}[may] be appropriate for
high-integrity systems. Other uses of No_Dependence can also be
appropriate for high-integrity systems.
Modify H.6(17/2):
NOTE If any deferred task activation fails, the environment task is
unable to handle the Tasking_Error exception and completes
immediately. By contrast, if the partition elaboration policy is
Concurrent, then this exception {can}[could] be handled within a library
unit.
Modify J.10(8/2):
NOTE An implementation {can}[may] support a similar On parameter on
pragma Unsuppress (see 11.5).
Modify J.15.1(6/3):
NOTE The name in a pragma Inline {can}[may] denote more than one entity in
the case of overloading. Such a pragma applies to all of the denoted
entities.
!discussion
The ISO rules from the Directives part 2 (often referred to as the
drafting standard) are summarized in AI12-0442-1.
The editor checked the drafting standard and examples have the same
limitations on wording as notes, so examples have been included here.
---
See AI12-0442-1 for details on the overall number of occurrences of the
restricted words.
The cases shown in this AI are all cases where a simple replacement of a word
with "can" is sufficient to create an understandable note. More complex cases
are found in AI12-0442-1.
---
We have several options for dealing with these notes.
First, since these are notes and examples, we have the option of eliminating
them completely, either from the ISO version only, or from both versions (in
which case the note probably would be moved to the AARM). But we ought to do
that only in cases where a rewording is not valuable for one reason or another.
Those cases do not appear in this AI.
Second, 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).
Therefore, simply changing the text of the RM (and therefore of the ISO
standard) is preferred for simple cases such as those given here.
!comment Not all Corrigendum sections are given here.
!corrigendum 4.3.3(32/3)
Replace the paragraph:
NOTES
11 In an array_aggregate, positional notation may only be used with two
or more expressions; a single expression in parentheses is
interpreted as a parenthesized expression. A named_array_aggregate, such
as (1 => X), may be used to specify an array with a single component.
by:
NOTES
11 In an array_aggregate delimited by parentheses, positional notation can
only be used with two or more expressions; a single expression in
parentheses is interpreted as a parenthesized expression. An array_aggregate
delimited by square brackets can be used to specify an array with a single
component.
!corrigendum 9(11)
Replace the paragraph:
NOTES
1 Concurrent task execution may be implemented on multicomputers,
multiprocessors, or with interleaved execution on a single physical
processor. On the other hand, whenever an implementation can determine that
the required semantic effects can be achieved when parts of the execution of
a given task are performed by different physical processors acting in
parallel, it may choose to perform them in this way.
by:
NOTES
1 Concurrent task execution can be implemented on multicomputers,
multiprocessors, or with interleaved execution on a single physical
processor. On the other hand, whenever an implementation can determine that
the required semantic effects can be achieved when parts of the execution of
a single logical thread of control are performed by different physical
processors acting in parallel, it can choose to perform them in this way.
!corrigendum 9.5.1(19)
Replace the paragraph:
NOTE 1 If two tasks both try to start a protected action on a
protected object, and at most one is calling a protected function, then only
one of the tasks can proceed. Although the other task cannot proceed, it is
not considered blocked, and it might be consuming processing resources while
it awaits its turn. There is no language-defined ordering or queuing presumed
for tasks competing to start a protected action — on a multiprocessor such
tasks might use busy-waiting; for monoprocessor considerations, see D.3,
"Priority Ceiling Locking".
by:
NOTE 1 If two tasks both try to start a protected action on a
protected object, and at
most one is calling a protected nonexclusive function, then only one of the
tasks can proceed. Although the other task cannot proceed, it is not considered
blocked, and it can be consuming processing resources while it awaits its
turn. Unless there is an admission policy (see D.4.1) in effect, there
is no language-defined ordering or queuing presumed for tasks competing to start
a protected action — on a multiprocessor such tasks can use busy-waiting; for
further monoprocessor and multiprocessor considerations, see D.3, "Priority
Ceiling Locking".
!corrigendum 9.5.1(22.1/2)
Replace the paragraph:
22 The pragma Detect_Blocking may be used to ensure that all
executions of potentially blocking operations during a protected action
raise Program_Error. See H.5.
by:
22 The aspect Nonblocking can be specified True on the definition
of a protected unit in order to reject most attempts to use potentially
blocking operations within the protected unit (see 9.5). The pragma
Detect_Blocking can be used to ensure that any remaining executions of
potentially blocking operations during a protected action raise Program_Error.
See H.5.
!corrigendum 10.1.2(31/2)
Replace the paragraph:
The limited_with_clause may be used to support mutually dependent
abstractions that are split across multiple packages. In this
case, an employee is assigned to a department, and a department has
a manager who is an employee. If a with_clause with the reserved
word private appears on one library unit and mentions a second
library unit, it provides visibility to the second library unit, but
restricts that visibility to the private part and body of the first
unit. The compiler checks that no use is made of the second unit in
the visible part of the first unit.
by:
The limited_with_clause can be used to support mutually dependent
abstractions that are split across multiple packages. In this
case, an employee is assigned to a department, and a department has
a manager who is an employee. If a with_clause with the reserved
word private appears on one library unit and mentions a second
library unit, it provides visibility to the second library unit, but
restricts that visibility to the private part and body of the first
unit. The compiler checks that no use is made of the second unit in
the visible part of the first unit.
!corrigendum 10.1.3(22)
Replace the paragraph:
The body of procedure Inner may be turned into a subunit by rewriting the
package body as follows (with the declaration of Parent remaining the same):
by:
Example showing how the body of procedure Inner can be turned into a
subunit by rewriting the package body as follows (with the declaration of
Parent remaining the same):
!corrigendum C.6(25/4)
Insert after the paragraph:
10 Specifying the Pack aspect cannot override the effect of
specifying an Atomic or Atomic_Components aspect.
the new paragraph:
11 When mapping an Ada object to a memory-mapped hardware
register, the Ada object can be declared atomic to ensure that the
compiler will read and write exactly the bits of the register as specified in
the source code and no others.
!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: 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-0440-1, 9.5.1(19/5) says:
NOTE 1 If two tasks both try to start a protected action on a
protected object, and at most one is calling a protected nonexclusive
function, then only one of the tasks can proceed. Although the other
task cannot proceed, it is not considered blocked, and it {can}[might] be
consuming processing resources while it awaits its turn. Unless there
is an admission policy (see D.4.1) in effect, there is no
language-defined ordering or queuing presumed for tasks competing to
start a protected action - on a multiprocessor such tasks might use
busy-waiting; for further monoprocessor and multiprocessor
considerations, see D.3, "Priority Ceiling Locking".
But there is a second "might" in here, it too needs to be replaced by "can".
----------------
9.11(1) and 9.11(4) both contain "might", that needs to be replaced by
"can":
Modify 9.11(1):
The following example defines a buffer protected object to smooth variations
between the speed of output of a producing task and the speed of input of some
consuming task. For instance, the producing task {can}[might] have the
following structure:
Modify 9.11(4):
and the consuming task {can}[might] have the following structure:
"Might" is better, but it's not allowed, so whatever. These were added to AI12-0440-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.]
****************************************************************
Questions? Ask the ACAA Technical Agent