!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 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; -- see 3.9 -- By default, Simplify does nothing, but it {can}[may] be overridden in extensions of Expression 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) @drepl @xindent<@s9, positional notation may only be used with two or more @fas; a single @fa in parentheses is interpreted as a parenthesized expression. A @fa, such as (1 =@> X), may be used to specify an array with a single component.>> @dby @xindent<@s9 delimited by parentheses, positional notation can only be used with two or more @fas; a single @fa in parentheses is interpreted as a parenthesized expression. An @fa delimited by square brackets can be used to specify an array with a single component.>> !corrigendum 9(11) @drepl @xindent<@s9> @dby @xindent<@s9> !corrigendum 9.5.1(19) @drepl @xindent<@s9> @dby @xindent<@s9> !corrigendum 9.5.1(22.1/2) @drepl @xindent<@s9<22 The @fa Detect_Blocking may be used to ensure that all executions of potentially blocking operations during a protected action raise Program_Error. See H.5.>> @dby @xindent<@s9<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 @fa 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) @drepl The @fa 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 @fa with the reserved word @b 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. @dby @i @fa @i @fa @i 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) @drepl 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): @dby @i !corrigendum C.6(25/4) @dinsa @xindent<@s9<10 Specifying the Pack aspect cannot override the effect of specifying an Atomic or Atomic_Components aspect.>> @dinst @xindent<@s9<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 ****************************************************************